|
Vadim @StresStimulus Administrator Posts: 583
5/4/2011
|
When you are saying “it seems to halt randomly” I assume that you mean that at some point in the test the progress bar (below) stops displaying any changes. When you are saying “but no iterations will be completed” does it mean that ended test Iterations counter shows zero or it stopped incrementing?
Here are a few thoughts. It seems that the problem is on the server, but first you should rule out possible client issues.
- Make sure that StresStimulus did not hang. When click Abort, test should stop and the progress bar should disappear.
- Make sure that when test halts, Started Test Iterations > Ended Test Iterations and Sent Requests > Receive Requests.
- Client overload. Check how Elapsed Time counter is advancing. While a few seconds hesitation is OK, if it stops for a long time, your client is overloaded. Check (in task manager or perfmon) that CPU utilization does not exceed 85-90% capacity. To save client resources, verify that in StresStimulus Options -> “Purge response bodies” box is checked (default). If client is overloaded, test will progress slower, so you may need to reduce number of virtual users or split them between several machines.
Other than this, based on the information you provided, it looks like in your tests, all virtual users got blocked and are awaiting server responses that are not coming back.
StresStimulus replays multiple iterations of a test scenario for multiple virtual users concurrently. Every VU needs to receive server responses in order to continue iterating. While waiting for responses, VU is temporary blocked. Blocking a particular user does not prevent other users from sending requests, because StresStimulus simulates users asynchronously. However if the server is overloaded, it can reach the point when at least one request from every virtual user is queued. This will cause all virtual users to be blocked. In this case you will see that counter of Sent and Received requests will stop incrementing. If this is the case, it explains why removing certain requests (css and javascript) from your test case makes blocking happen less often, since you are reducing the server load. By the way, one of the benefits of stress tests is to determine at what load level the server will no longer able to keep up with incoming requests, so you may be onto something.
Suggestions on troubleshooting:
- In Load Pattern select Step Load and start with small number of VU, while providing gradual VU ramping (see example below). Make sure that with the small number of VU the Ended Test Iterations counter increments. This will indicate that the server works fine when the load is low.
- As load is increasing, keep an eye on Requests Sent and Received counters. The difference is the number of pending requests (not yet returned by the server) that should not grow out of control.
- If you reach a number of VU when Received counter stopped incrementing, it marks your operational ceiling.
Please let me know if you experience is inconsistent with what I described, so we can look into you case further.
Side note 1. Fiddler does not impose any timeout limit for slow server response, but web servers typically have default timeout, after which even overloaded server should return response with the error code (in 500s range). For example, default timeout for ASP.NET is 110 seconds. You may want to reduce the timeout on your web server for the purpose of load testing. It will not increase you server scalability, but you would be able to better track server errors.
Side note 2. In the coming release (next week) we will upgrade Progress bar with 2 additional counters: Errors and Pending Requests. It should make it easier to track test progress.
Cheers,
-Vadim
|