3 Replies Latest reply on Oct 1, 2013 4:05 AM by Divya NameToUpdate

    Very high response times for some transactions

      Hello Team,


      I would like to ask you if you know why some transactions have response times very highs. When I try these scripts in the workbench (installed in the execution server machine), the time response is good.


      Could it be because I have a lot of scrips (more or less 20) in the same project that running at the same time ? I do not have this problem with other transactions that are alone in a project.



      Thank you !

        • 1. Re: Very high response times for some transactions
          Dan Egner

          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:


          MeasureStart("Proxy Login");
          WebSetProxy(WEB_PROXY_HTTP, proxy, 80);
          WebSetProxy(WEB_PROXY_HTTPS, proxy, 80);
          WebSetProxyAuthNtlm(proxy_user, proxy_password);
          MeasureStop("Proxy Login");


          MeasureStart("Web Requests");
          etc etc...
          MeasureStop("Web Requests"");


          Then those measures might tell you whether the problem was the proxy.

          • 2. Re: Very high response times for some transactions

            I've noticed a similar behavior when I've been monitoring web sites that are bloated with additional content such as RSS feeds, JavaScript files, user ribbons, etc. The response times for a single page have been as high as 45 seconds via Workbench & Execution Server, but only a few seconds when tested manually.


            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

            • 3. Re: Very high response times for some transactions

              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.