Timedout on long response tree

[gbarat87]

Hi,
on a moodle 4.1, I have one stack question that has a big "potential response tree" (60 node) and we reach a timeout before the last node, so the answer cannot be saved. I have the same timeout if I create test case for an expected answer note to far in the tree.
Then I have updated the qtype_stack | castimeout value to a bigger number (100). With that, the question could reach the last element of the tree.
However, a value superior to 120 will crash our page.
And it does look like it worked well in a previous 3.9 moodle version , doesn't matter which CAS connection timeout value is.

Do you have any advise on what could potentially be the problem, or how I can improve it or make it more efficient ?

Thanks,
Guillaume

[sangwinc]

I'm sorry you are having problems.

There will always be limits to the "size" of a question. When I designed STACK, and the PRT system, I had in mind typically having 3-4 nodes with perhaps 12 max. I never envisaged people would write such large or complex questions. A question with over 50 nodes in a PRT is likely to be close to "unmaintainable". So, the question is this: what are you doing?

E.g. if you are testing the entries in an n*m matrix with individual nodes, then you'll get lots of nodes quickly. In this (silly example) case we need a better design - a function which with one node will solve that problem.

I'd like to know why the current design results in such complexity. We probably need a better design. Efficiency (alone) will never solve all problems...

[aharjula]

Also worth noting is that there have been significant changes in the way PRTs execute during the last few years. So, for this, it would really help to know what version of STACK is in use. While there are indeed upper limits for sensible PRT node counts both for singular PRTs and over PRTs of a given question, changes have lessened the effect of that N in this quite a lot and made the cost much more connected to what those nodes actually do.

That being said, sometimes the N just gets too high. Also, upping STACK's own timeouts will only work up to a point; at some point, the timeouts of PHP and other parts of the webserver also start affecting things.

[gbarat87]

Hi, Thank you for these details answers.
The version we are using is 4.4.2 (2023010400)

The purpose of this question with that much nodes is to answer a maths problem, where there can be different answer, and the user would not get 0 score if the answer is partially correct. So every node would cover what seems to be a possible answer with decreasing point. Each node match a specific answer with an appropriate comment to explain what went wrong or what is missing in the answer to get the full grade.

I hope this is more clear, even if I can't get too specific.
Guillaume

[sangwinc]

Gosh, that's a lot of feedback. I'm sorry this has become out of hand. If you email me the question privately at Edinburgh I'll take a look and reconsider the design. However, there are limits to what we can support of course.

Chris