Creating highly targeted load tests for your web server doesn’t have to be complicated. And it won’t be, at least not if you know what to look for.

The secret is to approach a load test with the mind of a developer. You’re not going to run a test just to punish your web server. You’re trying to gather valuable data that will aid you in keeping your web applications fast and responsive. To do this, let’s look at two simple steps to create a scientifically sound load test.

1. To plan your test, think like a user.
The first step is to outline exactly what type of web experience you’re testing for. Are you expecting users to log onto your site and remain for hours at a time? Or are a large number of users entering and leaving the site in short spurts? Or, are you expecting your about-to-be-released video to go viral, and you want to be sure your server can handle the load? No two websites are identical, and the same goes for the user experience on your site.

Let’s take a look at an example. An online shop might find it best to define the number of visits and purchases per hour that its servers must be able to handle. With this information, the shop can calculate it down to a value of each new visit and/or purchase per second. An example of this could be an hour-long test configured to send five new visitors to the site per second, simulate them surfing the product catalog, and have them start a new purchase every second.

2. Find the data that really matters.
Now that your load test is up and running, your next step is to comb through the mountain of incoming data to understand what’s happening on the server. During the load test for our hypothetical online shop, new simulated users are coming to the site and old simulated users are leaving the site. To judge the response time of the web server, we need to look at the number of parallel users. If the web server is slow, you’ll have a large number of virtual users, and if it’s fast, that number will be smaller.

When the results of a load test show unacceptable response times, it is often assumed that the network is the cause of the problem. In reality, this is seldom the case. Fortunately, it is quite easy to check this using test measurement data. Simply compare the response time for a static image (such as JPEG, GIF, or PNG) with the response time for a dynamically created HTML page of approximately the same size.

Consider this example:
A) The response time for a static GIF image of 200 kB is measured at 60 milliseconds.
B) The response time for a dynamically created HTML page with a size of 400 kB is measured at three seconds.

Assuming the response time of the static image depends solely on the network bandwidth (which is not always the case, but is useful for our purposes in this example), the dynamically created HTML page should have a response time of 120 milliseconds since it is only twice the size of the image. Since the actual response time of the HTML page is three seconds, the web application uses at least 2880 milliseconds (3000 minus 120) to produce and send the page.

However, one successful test does not guarantee a perfect application. You should be running load tests after any modification is made to the web server or application (i.e. new software release, upgrading database, etc.). These tests should run for at least 30 minutes, because often a web server does not crash instantly when it’s overloaded. Many can handle a large load for a few minutes, but might crash later after 15 or 20.

With these tips in mind, you’ll be on track to pinpointing your application’s performance issues. Perfection takes time, but as you tweak your tests to emulate your real-world traffic, your response times should gradually improve.