Successful performance analysis depends on the ability to identify bottlenecks in the application or system infrastructure. A bottleneck could be caused by any object on a page that is taking longer than other page objects to fully load, or it could be an overloaded segment of the network or a security process that is delaying the browser’s requests and responses.
How easy is it for you to get to the root cause of an issue, isolating a problem down to a component or procedure?
Analysis and tuning is not a “one and done” type of event, but rather a cyclical process of evaluation and elimination of performance bottlenecks, using iterative load testing of the application. Every pass of a load test could uncover new issues in the system, as the elimination of one larger issue in a previous pass might unmask other issues that were previously shadowed.
The errors found should become more granular with each testing cycle and subsequent remediation, so the results of iterative testing are stronger, faster applications with fewer performance defects. If we know that an application has been tuned previously, new degradations to the system can be easily identified on the latest run of the test.
Waterfall charting can be a useful tool for identification of root cause. Through the graphical representation of each request against time, we can easily see the objects causing degradation in the test. The different sub-timers included in the graphed request, such as “time to first byte” and “response transfer time,” can give us insight into suggested remediation for the object. Here are some things to look at when performing any kind of load test analysis.
Time to First byte
A long first byte time indicates that the host server is delayed in getting the beginning of the requested information back to the browser. This is most frequently caused by an overloaded host server, or a congested pathway between the server and the browser.
Remediation on an object with a long first byte value might include having it served from a different host, moving the serving host to another location in the infrastructure, or possibly optimizing the object through the use of a Content Delivery Network (CDN)
Response Transfer Time
A long transfer time might indicate that the object itself might be oversized for the application. This could be rectified by allowing the application to call down the information contained in this object through a series of smaller requests, relying on the nature of the browser to perform these requests in parallel.
Gaps Between Requests
In the waterfall report, it might appear that there is a short length of time between the conclusion of one request and the beginning of processing for the next request. The most frequent reason for this is that the browser requires extra time to establish a connection to the target Web server. This can be tuned in the application.
The comparison of a recent waterfall chart to a historical version can give you the necessary detail for your first assessment of root cause. Also, by graphically seeing the components and infrastructure used by the site, you can correlate information he has received from other sources regarding network activity or recent outages, which might also suggest root cause.
- What Makes a Good Load Test Report?
- How Ready are you for Heavy Load on Your Website?
- How Role-Playing Games Can Save Your App