Category list

Recipe 11.2 Benchmarking Apache with ab

Problem

You want to benchmark changes that you are making to verify that they are in fact making a difference in performance.

Solution

Use ab (Apache bench), which you will find in the bin directory of your Apache installation:

ab -n 1000 -c 10 http://www.example.com/test.html

Discussion

ab is a command-line utility that comes with Apache and lets you do very basic performance testing of your server. It is especially useful for making small changes to your configuration and testing server performance before and after the change.

The arguments given in the previous example tell ab to request the resource http:// servername .com/test.html 1000 times ( -n 1000 indicates the number of requests) and to make these requests 10 at a time ( -c 10 indicates the concurrency level).

Other arguments that may be specified can be seen by running ab with the -h flag. Of particular interest is the -k flag, which enables keepalive mode. See the following keepalive recipe for additional details on this matter.

There are a few things to note about ab when using it to evaluate performance.

ab does not mimic web site usage by real people. It requests the same resource repeatedly to test the performance of that one thing. For example, you may use ab to test the performance of a particular CGI program, before and after a performance- related change was made to it. Or you may use it to measure the impact of turning on .htaccess files, or content negotiation, for a particular directory. Real users, of course, do not repeatedly load the same page, and so performance measurements made using ab may not reflect actual real-world performance of your web site.

You should probably not run the web server and ab on the same machine, as this will introduce more uncertainty into the measurement. With both ab and the web server itself consuming system resources, you will receive significantly slower performance than if you were to run ab on some other machine, accessing the server over the network. However, also be aware that running ab on another machine will introduce network latency, which is not present when running it on the same machine as the server.

Finally, there are many factors that can affect performance of the server, and you will not get the same numbers each time you run the test. Network conditions, other processes running on the client or server machine, and a variety of other things, may influence your results slightly one way or another. The best way to reduce the impact of environmental changes is to run a large number of tests and average your results. Also, make sure that you change as few things as possible - ideally , just one -between tests, so that you can be more sure what change has made any differences you can see.

Finally, you need to understand that, while ab gives you a good idea of whether certain changes have improved performance, it does not give a good simulation of actual users. Actual users don't simply fetch the same resource repeatedly, but they obtain a variety of different resources from various places on your site. Thus, actual site usage conditions may produce different performance issues than those revealed by ab .

Recipe 11.3 Tuning Keepalive Settings

Problem

You want to tune the keepalive- related directives to the best possible setting for your web site.

Solution

Turn on the KeepAlive setting, and set the related directives to sensible values:

KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 15

Discussion

The default behavior of HTTP is for each document to be requested over a new connection. This causes a lot of time to be spent opening and closing connections. KeepAlive allows multiple requests to be made over a single connection, thus reducing the time spent establishing socket connections. This, in turn, speeds up the load time for clients requesting content from your site.

In addition to turning keepalive on, using the KeepAlive directive, there are two directives that allow you to adjust the way that it is done.

The first of these, MaxKeepAliveRequests , indicates how many keepalive requests should be permitted over a single connection. There is no reason to have this number set low. The default value for this directive is 100, and this seems to work pretty well for most sites. Setting this value to 0 means that an unlimited number of requests will be permitted over a single connection. This might allow users to load all of their content from your site over a single connection, depending on the value of KeepAliveTimeout and how quickly they went through the site.

KeepAliveTimeout indicates how long a particular connection will be held open when no further requests are received. The optimal setting for this directive depends entirely on the nature of your web site. You should probably think of this value as the amount of time it takes users to absorb the content of one page of your site before they move on to the next page. If the users move on to the next page before the KeepAliveTimeout has expired, when they click on the link for the next page of content, they will get that next document over the same connection. If, however, that time has already expired , they will need to establish a new connection to the server for that next page.

You should also be aware that if users load a resource from your site and then go away, Apache will still maintain that open connection for them for KeepAliveTimeout seconds, which makes that child process unable to serve any other requests during that time. Therefore, setting KeepAliveTimeout too high is just as undesirable as setting it too low.

In the event that KeepAliveTimeout is set too high, you will see ( i.e ., with the server-status handler -see Recipe 11.4) that a significant number of processes are in keepalive mode, but are inactive. Over time, this number will continue to grow, as more child processes are spawned to take the place of child processes that are in this state.

Conversely, setting KeepAliveTimeout too low will result in conditions similar to having KeepAlive turned off entirely, when a single client will require many connections over the course of a brief visit. This is less easy to detect than the opposite condition. In general, it is probably better to err on the side of setting it too high, rather than too low.

Since the length of time that any given user looks at any given document on your site is going to be as individual as the users themselves , and varies from page to page around your web site, it is very difficult to determine the best possible value of this directive for a particular site. However, it is unlikely that this is going to make any large impact on your overall site performance, when compared to other things that you can do. Leaving it at the default value of 15 tends to work pretty well for most sites.