i'm having hard time understanding the load test result in vsts to find when the application breaks under load.
Is there any indications to find it. I searched about this in google, asked in stack overflow but i dint get any clear answer about it.
2
-
Can you give some more context? What exactly do you mean by the "application breaks"? Are the responses from the web service coming back with 500 errors? Is it not responding at all? Is there some other behavior you are observing? Assuming your app is running on IIS, usually you can tell by tracking some of the performance counters whether the application pool has reset unexpectedly, or is hung, but if there is an error in the state of the app itself then you may need to rely on validating the responses themselves.– Sam WoodsCommented Oct 17, 2013 at 21:52
-
If an application have the maximum capacity of running 100 concurrent users without any interruptions/delays/hangs etc., what if we try loading them with 150 or more users, so how will it behave? How to find the maximum capacity of application that can hold as many users without any hassles. makes sense?– VigneshCommented Oct 18, 2013 at 8:48
Add a comment
|
1 Answer
Let me start by saying that analyzing the results of performance tests is a complex exercise. You need to have some understanding of how the system works, what parts of the system use up what resources (CPU, Memory, Disk I/O, Network Bandwidth, etc, etc). You also need to understand the architecture of your app and monitor all of the applicable systems and processes. It is often a good idea if you are not an expert, to enlist the help of an expert while analyzing the results.
There are many ways that a stress/load test can "break" your application. The obvious way would be that whatever process is hosting the application will crash. This is a little tricky to discover if it is an IIS application pool because IIS will automatically restart it for you. Often if this happens you'll see a rise in memory and cpu usage on the system, then it will bottom out for a bit, then begin climbing back up. This is usually an indication that something went horribly wrong. The fact that IIS recovered is great, but it usually means at the very least that all of the current sessions were immediately expired and can have other unintended consequences.
Another way could be that dependent services, processes or systems crash in a similar way and may or may not restart automatically. You have to ensure you are monitoring each of these.
Another way could be that even though the process has not crashed, something internally has met some limit or threshold, or there is a bug in concurrency or some other defect preventing the application from behaving in the desired way. This will usually show up in results as errors being returned in the responses from your web server, 500 errors are the most likely so you will need to validate the results coming in.
Another way would be that even though nothing crashes, the system slows to a crawl. You will need to determine an appropriate threshold that various activities need to fall within. If a response that takes <1 second under normal load shoots up to over a minute to respond while under heavy load, even though the system isn't "broken", it is probably still not working well enough to consider functioning properly.
