Study and optimization of a Web server > Working conditions

Last update:
June 5, 2002

Presentation

Presentation
Working conditions
Panel of servers

Apache

Operation
Modules
Optimization solutions

Caching PHP

Presentation
Pages caching
Opcodes caching

Example

Optimization on Wysistat

Links

Apache 1.3
PHP Accelerator
ID.fr
Mesure d'audience

Study and optimization
of a Web server

Working conditions

The tests were carried out on a machine equipped with a processor AMD K6 450 MHz, of two operating systems, the version Mandrake 8.1 of Linux and Windows 98, and 128 Mo of RAM.
These tests consisted in evaluating the profit of performance brought by the solutions of optimization to the processing times.

Used tools

Two tools able to measure the processing times of requests on a Web server were used :

Apache Bench (ab) : tool provided in the distribution of Apache. It makes it possible to test the performances of any server by specifying a number of requests to send to the server with a concurrency level (simultaneity of the requests). If the concurrency level isn't specified, the tool sends a request, awaits the response, sends the following one, awaits the response, and so on until the sending of all the requests. It is also necessary to specify the URL of the document to which the requests apply (more infos...).
httperf : tool similar to Apache Bench. It is necessary to specify the server name, the document name, and the number of requests. This tool allows in addition to define sessions: each session corresponds to a user and includes a number of requests to send as well as the time between each request. A rate of sessions creation can also be defined (more infos ...).

The advantage of using two tools is to be able to compare measurements, and to see if times do not differ from one tool to another for the same test, what would tend to make think that one of the two tools provides distorted results.

1000 simultaneous requests : it is a question here of testing the capacity of the server to manage an abrupt rise of requests. A test consists in sending several requests simultaneously (for example 1000 simultaneous requests). For this kind of tests, the tool Apache Bench was used.

Example : ab -n 1000 -c 1000 http://172.16.48.2/idfr/compteur.php
This command means that 1000 request are launched ( -n 1000 ), that the concurrency level is 1000 ( -c 1000 ), and that each request relates to the file located at the URL http://172.16.48.2/idfr/compteur.php . That corresponds to 1000 simultaneous clients operating each one a request (thus 1000 connections are opened on the serter). We can also vary the number of simultaneous requests: for example we can launch 1000 requests, with a concurrency level equal to 500. In this case, the test program (ab) will make sure that the number of simultaneous requests does not exceed 500 during the test. These tests make it possible to know the reaction of the server, but this situation is not very real (it makes it possible nevertheless to test the robustness of the server) and it was necessary to carry out tests making it possible to simulate a situation corresponding to the behavior of the users, less abrupt and longer in time.
realistic simulation : now it is a question of generating requests in a real situatione : for example 225 simultaneous client making each one 50 requests. For this kind of test, the tool httperf was used because it allows to define sessions.

Exemple : httperf --wsess=225,50,0 --rate=150 --server=172.16.48.2 --uri=/idfr/compteur.php
This command means that 150 sessions are crated in on second ( --rate=150 ), that the number of sessions to create is 225, each session is composed of 50 requests ( 0 second between two requests ) ( --wsess=225,50,0 ) , and each request relates to the file /idfr/compteur.php located on server 172.16.48.2 . Each session opens a connection with the server, and uses this connection to send the requests and to receive the server reponses (persistent connection). Fixing the rate of sessions creation at 150 means that we simulate 150 users arriving on the server in one second. Consequently since 225 users are simulated, it is necessary less than 2 seconds so that they began all to carry out their requests (thus we deal with simultaneous users).

Contact - version française