{"id":6410,"date":"2024-11-01T09:03:27","date_gmt":"2024-11-01T13:03:27","guid":{"rendered":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/?p=6410"},"modified":"2025-04-04T10:02:50","modified_gmt":"2025-04-04T14:02:50","slug":"identifying-web-server-load-testing-bottlenecks-in-scatter-plots","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2024\/11\/identifying-web-server-load-testing-bottlenecks-in-scatter-plots\/","title":{"rendered":"How to Find Hidden Web Server Load Testing Bottlenecks in Scatter Plots"},"content":{"rendered":"

If you’ve been using average page load data to evaluate your website’s performance, you could be missing important bottlenecks that are reducing your conversion rates and causing customers to have a frustrating experience. \u00a0While averages are easy to understand, they cover up all of the details. After all, if the average load time of a page is 2 seconds, many users are seeing load times slower than that, but we don\u2019t know exactly how slow. The industry standard of expressing site performance in percentiles is technically accurate, but also doesn\u2019t give a full picture.<\/p>\n

Here’s a good example. \u00a0A recent client, a high-end retailer, showed excellent average page load times. \u00a0It looks like there wasn’t any slowdown at all in terms of page load times as the load increased to 2,250 concurrent users.<\/p>\n

\"\"<\/a><\/p>\n

What the average was covering up was a much wider range of response times than you’d imagine just by looking at the above chart. \u00a0That’s why we added scatter plots to\u00a0Web Performance Load Tester<\/a> and you can of course generate them in most modern load testing tools.\u00a0They plot every singe web page response time in a test, or can be focused on a single test case or even a single web page.<\/p>\n

\ufffc\"\"<\/a><\/p>\n

These plots provide us with a readily comprehensible overview of the range of web page load times seen by customers in different parts of the website. \u00a0While the average web page load time was fast, in reality the all important checkout and shopping cart process had a substantial number of responses within the 5-15 second range even at low load levels! \u00a0If you had relied on just the average load times you would have missed that all important detail that could be driving down the sales conversion rate and costing the company sales.<\/p>\n

Another troubling concern is the spikes circled in red. When the scattered load times bunch up in recognizable vertical lines, it is an artifact of how web page response times are measured. A web page response time is only recorded once the page has fully loaded. Prior to this, the page\u2019s loading time remains unknown. First, one user requests a page that the back end cannot serve, followed by another and another. The first bottleneck in the image above spans 35 seconds, indicating that the cause of the non-responsive page took 35 seconds to unblock itself and return the page content. Once this happened, the blocked page was served to all of the waiting users at once, creating the vertical stack pattern.\u00a0 The first user to request the blocked page waits the longest, the second a little less, etc, and the most recent user may not wait that much time at all. But no matter how long they waited, they all saw the page update at approximately the same time.<\/p>\n

You\u2019ll see the scattered load times line up like this when a call to a webpage\u2019s back end, whether directly to the database or an application server, is blocked. Often, this occurs due to a locked database table, but it can also result from any type of failure at any level. In this particular example, the servers were at about 40% CPU load when the blocks started occurring, so the problem wasn\u2019t server capacity.<\/p>\n

Some typical causes of a blocked\/locked page:<\/p>\n