[OpenSTA-users] Re: Timeout setting for individual requests
Brought to you by:
dansut
From: Daniel S. <dansut@OpenSTA.org> - 2005-09-29 18:34:11
|
Jeff Jewell wrote: > I ran some performance tests last week and started to see a strange > phenomenon with some of my timers when I got a lot of VUs in the > system. I started to see huge spikes every five minutes in a > couple of my timers. They would average response times at around > 30 seconds (yes, I know that's pretty long) That all depends what you are timing - if it is a "business transaction" that involves a couple of different actions then it isn't long at all. You don't tell us where you put your START/END TIMERs which might be important. > and then I would see a whole bunch of timers that ended at the same > time with numbers ten times that size or more. Then the numbers > would go back down again until exactly 5 minutes later when I would > see another huge spike. > > At first I thought it was some process running on the server every > five minutes, but I saw some requests generated at the same time that > returned in reasonable times. I remembered that I had set the > Timeout setting in the configuration file to 5 minutes. It then > dawned on me that what it looks like OpenSTA is doing is every five > minutes (or whatever the Timeout setting is set to) it's killing any > hung connections. Looking at the code it would seem that the Timeout setting from the TestExecuter_Web.ini file is used in the TestExecuter such that every configured millisecs a thread wakes up and enumerates through all the sockets with pending IO... on finding any that have been waiting longer or equal to that value that socket is foribly closed. This could suggest that you are see-ing this happen in your results as the timed out sockets are collected. > I had assumed that the Timeout setting was for timing out > individual requests, but it appears that I was wrong. Am I now > understanding correctly how the timeout setting works? It does look like the timeout setting does control the behavior of the cleanup thread rather than a specific socket value. If you want to be 100% sure of this then you can check the TestExecuter trace file for "Timeout generated for socket ..." messages and match them to your timers ending. > If so, then is there a way to set a timeout setting for individual > HTTP requests so that they don't all get timed out together? Not that I can find right now... > Also, I'm curious as to why some of the requests are returning fine > in 20-30 seconds but others are taking 300-500 and still not > returning a response. There doesn't appear to be any middle ground, > as there are with some of my other timers where I see steady > increases in response times. For this one particular timer it seems > to be all or nothing; either I'm going to get a response in the > first 30 seconds or I'm not going to get any response at all. Do > any of you have any suggestions for troubleshooting this? Are the larger values always at the timeout? If they are then that would seem to say that the timed action either works (20-30s) or fails (hangs until timed out). I'd be looking at what the action is and if this is something that might fail and hang on your application server. > Finally, why do some requests return with a response time of 0? > Towards the end of my test run almost all of the main GET requests > in this timer have response time of 0 and size 0. The server is > definitely overloaded so is it just refusing requests for this > page? Chances are that a HTTP response time of 0 is really just "very small" and not actually 0. You want to be looking at your HTTP code returned to troubleshoot this. Hope this helps, /dan -- Daniel Sutcliffe <DanSut@OpenSTA.org> OpenSTA part-time caretaker - http://OpenSTA.org/ |