Entrepreneur, Blogger, Author of "Mobile Test Automation with Appium"

On Monday, September 06, 2010 by Nishant Verma in , ,
When I think of Performance Testing, the response time is not the only thing which comes to my mind. Performance Testing should not be done alone to capture the response time.
Based on the nature of application and it’s usage, minimally we should run two types of test. One to find out how many concurrent users the system will support for a given response time.  I have really seen a decline in the need of performing these kinds of test. Application Performance is not always about the response time of web service. As a part of Performance Testing, one should also run Soak Test. Soak tests are long duration tests on the system with a static number of concurrent users that tests the overall robustness of the application. The intention of this test is to identify any performance degradation over time through memory leaks, increased GC or any other problem in the system.
To get the memory footprints of the application, we need to set up some specific counters in the server where the application is installed. Some of those counters are: Available Mbytes, Virtual Bytes, Private Bytes, # Bytes in all heaps, %Time in GC, Gen 1 Heap Size, Gen 2 Heap Size, Requests/sec. Once we run the test and get all the data, we need to plot the data in a graphic format so that we can find out the pattern and trend.
A typical memory usage graph would look like:
image
So if we see the graph above, there is little degradation of memory over the period of 3 hours of test. If there is any significant dip then we need to further break down the test and capture some more counters in order to find out why the memory is degrading.
Apart from this memory aspect, we also need to find out the windows resource aspect which would typically contain plotting of % Time in GC, Available MBytes, Request/Sec and some more counters depending on the specific needs.
To me Performance Testing is more to do with these graphical representation of Application data and System Usage rather than just capturing the Average Response Time. Moreover it’s easy to educate/convince anyone  on the trend and plotting rather than just number.
Web Analytics