Load testing a web server using ab Apache HTTP server benchmarking tool

As long as your web server is running stably and stably giving the requested content to visitors, everything is fine. But did you ask yourself the question: what will happen if the load on the server increases? What if the number of requests per unit of time doubles? Three times Ten times? How to find out the answer to this topical "what if?". In today's article we will look at the basics of load testing web servers using the ab - Apache HTTP server benchmarking tool , a tool that will allow you to determine the maximum possible number of simultaneous requests that your web server installation can handle.

Cooking

The ab utility comes bundled with Apache , so if you have it installed, you already have everything you need. In today's note, we will practice on the default Apache 2.2.14 installed in Ubuntu Server 10.04.2 LTS . The configuration of the equipment (to whom it is interesting is rather weak) and I will not give Apache settings, because there is no point in this article. The purpose of this note is a small overview of the ab utility, and not an analysis of the performance of specific software on a particular hardware. Within the framework of the example, we will perform a test of return by the server:

• HTML file test.html size 177 bytes;
• a small PHP script test.php , which is shown below.

All files are located in the root of the DocumentRoot server. The PHP script code was used like this:

To reduce the impact of network latency, use a system to perform tests, the network bandwidth from which to the server being tested is as high as possible.

Request html file

So, let's begin. To begin, let's organize the load on our server at one thousand consecutive requests. To specify the number of requests, use the '-n' option. The port number can be omitted if it is not different from the 80th:

So, what happened with us (the conclusion is not fully cited, omitting insignificant moments so far). During testing, the utility will inform you about the progress of work:

Further you will see information about the server software version, its name, which document was loaded and what is its size:

And further, in fact, the results:

As seen:

• Concurrency Level: the number of simultaneously sent requests - 1;
• Time taken for tests: a thousand requests to the server took 1.5 seconds;
• Complete requests: successfully received a response to all a thousand requests;
• Failed requests: failed requests - zero;
• Write errors: write errors - zero;
• Total transferred : total transferred data: 453,000 bytes;
• HTML transferred : of which “useful” HTML is 177,000 bytes;
• Requests per second : the average number of requests per second was 666.58
• Time per request : the average time per request is 1.5 milliseconds
• Transfer rate : the data exchange rate with the server was 294.88 kilobytes per second.

Further, in the output there is information about the time spent on network connections:

And for servicing requests by the server:

As you can see, the server successfully coped with thousands of consecutive downloads of a static small file. Let's now see how the server will behave if the entire thousand requests are sent to it simultaneously , specifying it with the option '-c' :

Here, the test could not be completed due to the fact that after sending 804 requests simultaneously, the server stopped accepting incoming connections. Experimentally, by reducing the number of simultaneous requests, it was found that my Apache painlessly in the current configuration can handle approximately 300 simultaneous non-keep-alive requests.

Naturally, with Keep-Alive requests, the situation will be even worse, since Apache's server resources are not released so quickly. To test with Keep-Alive connections, just add the '-k' option:

PHP Script Request

With the work of scripts, the situation is naturally different. Here, the server needs not just to give you the file, but to start the interpreter, wait for its output and return the output to the client. And, of course, the work of the interpreter will take a certain amount of system resources, which will also affect the performance of the server as a whole.

Let's try to request our simple script a thousand times, making 300 requests at the same time:

As you can see, the server successfully coped with requests, but the processing time increased significantly, averaging 44 milliseconds per request, while the return of a small HTML file of about the same size was only 13 milliseconds.