One possibility is that the proxy server that is used by the execution server is slower that the proxy server used when you run the script from the TM ART Monitor Workbench.
If you have proxy statements in your script you could put in some MeasureStart() and MeasureStop() to get more info.
Here is what I am talking about:
WebSetProxy(WEB_PROXY_HTTP, proxy, 80);
WebSetProxy(WEB_PROXY_HTTPS, proxy, 80);
Then those measures might tell you whether the problem was the proxy.
Unfortunately I haven't figured out a workaround for it, so I've had to comment out the loading of these JS files and such - which of course doesn't result in very accurate response times either, but at least that way it's a bit closer to the perceived reality
When setting thresholds the user simply specifies a multiplier for the calculation of the threshold values. The average response times of the timers are multiplied by these factors, and the
boundaries are set accordingly. For example, a multiplier of 3 means you set a boundary three times higher than the average response time of the timer in the TryScript test.
Without obtaining results from TryScript this is not possible, so changing "Set Response Time Thresholds" to be enabled by default would not make sense.
The thresholds will not stop the monitor from running,you can set the ExecTimeout in the SVAppServerHomeConf.xml file to achieve what you want, see the following notes:
ExecTimeout in SVAppServerHomeConf.xml: this setting is used to kill a long running monitor execution regardless of what stage it is at. For example, if a monitor were to get stuck at a certain point, but this stuck point was not generating an error then we would need a way to kill the monitor and this is what this value is for. So if the execution server does not execute and finish before this value expires then the monitor will be killed off.
A timeout should cause the transaction to fail with an error in which case the timer can be excluded from calculations.
The MeasureStop function has a second parameter, bIgnoreOnError, when enabled the measured time is included in calculations if no error has occurred since the timer started. So the timer will be excluded if an error occurs between MeasureStart and MeasureStop.
In regards to your query about " if I amend the execution time out to 5 minutes and the transaction was stuck, execution will automatically end in 5 minutes and will return values?"
It will return the error message in the status column and the details of that error message will be mentioned in the Resultfile for that transaction.