Principles of HTTP benchmarking

In benchmarking a web server, the aim is typically to determine the number of requests per second the server is able to sustain, whilst satisfying certain constraints. Typical constraints include:

• The requirement that a client should have to wait no longer than 'n' seconds for a response. ('n' is typically low, around 5-8 seconds).
• No valid request should receive an error message as a response.
• The requests should be selected at random from a large docroot, to ensure that the web server's caching mechanism is fully exercised.

In order to conduct web server benchmarking, a system with at least the following components is required:

• A server running the web server software under test
• One or more clients running load generating software.
• A network connecting the clients to the server which is free of other traffic, and will not be saturated by the planned tests.

Under no circumstances should one attempt to benchmark a server by running the load generating software on the server itself. The web server and benchmark software will compete for CPU, and any results obtained will be extremely inaccurate.

A typical benchmarking installation

Figure 1 illustrates a typical network layout for web server benchmarking. A number of clients are connected via a switch to the server under test. The server in this example has two network cards, to increase the bandwidth available to it, and decrease the likelihood of the network becoming the bottleneck during the tests. In practice, the actual bandwidth to the server that will be required will be a function of the server hardware, and the type of tests being performed. It's possible to saturate a server from a single client without saturating the network when dynamic content generators are being tested or when requesting large numbers of very small files, but a web server serving large static files may be able to supply data at several hundred Mb/s.

Figure 1: Typical Benchmarking Network

1#1

The network in use is private, and no machines other than those required for the tests are connected to it, in order to eliminate the effects of externally generated network trafic spikes on the tests.