Congratulations: you’ve run a few LoadImpact load tests and you’re anxiously poring over the results. You’ve probably already gained a few insights about what you might improve. You’ve seen some areas you want to explore further. And you’ve found some mysterious status codes in the URLs tab on the test results page.
Let’s dig into those mysterious status codes and strip away the mystery.
Here’s an example. We ran a simple, 50 VU over 5 minutes, test against a simple WordPress site on a shared hosting platform. This is definitely not a robust - nor typical - scenario for many developers, but it illustrates some response status codes and where they come from.
On our URLs tab after that simple sample test, the hosted .js files and other plugins all returned (green) 200 codes - suggesting they all loaded consistently and correctly. (For example, these also included .css files and plugins like WooCommerce.)
Yet the main page URL was listed three lines with different status codes. The three status codes were 500 Internal Server Error, 508 Unknown, and 200 OK.
Sample URL results similar to those lilsted in the article
Where do you begin in figuring out these codes? It’s more straightforward than it might at first appear. Take a look at one of your recent tests, too, as we talk about this example.
In our example, the 500 code happened, as we were told in the Count column, 3 times, the 508 code 148 times, and the 200 code 265 times. Why would that be?
As our lower-performance shared hosting server took on more load, the server wasn’t up to the task, returning a 508 code and then a 500 code as the performance degraded. It might have been hardware disk access, a database connection, or the like.
Look at your test results to see if you see similar behavior. Look, too, at the min/max and avg columns. They list the minimum and maximum - and average - load times for those URLs. In our example case, the 200 codes loaded with about a 10 second average load time (still unacceptable, of course) and the 50X codes with about a 30 second load time.
What we’ve learned from these numbers: first, no matter how light the load, the page is loading much too slowly according to our load tests. Second, if we anticipate any additional traffic at all, the hosting plan we’re currently using is completely unacceptable over about 250 users. If we don’t improve the site performance, we can assume that we would lose business for any amount of concurrent users over that number.
Interesting, right? You may want to dive into your URLs tab, too. (Can’t find it? Click on a test in your dashboard, and then click a row underneath “Results.” Then click the URLs tab underneath your results graph.)
As you dig in, you may find the same test delivers different results, so watch for particular trends. (Pro tip: click the three stacked dots on the right of any particular URL row to add that result as a graphed metric on the Metrics tab for easy tracking.) As we ran this sample test more than once, we found that the time of day seemed to dictate our performance on a shared server, with performance degrading dramatically with as few as 50 users.
Good luck in your performance testing, and let us know what insights you find on the URLs tab. (If you want to dig in deeper, or would like to dig into more of the status code details, check out our knowledge base article here).