Let's continue with the series of articles about Apache performance tuning. Remember that in the previous ones, I approached the topics about dynamic modules (
I and
II) and directives (
I and
II).
So after reviewing the directives which allow to fit the global configuration of Apache, I am going to focus on a couple of tools used to adjust the values of those directives, based on the available hardware and the kind of service which wants to be offered.
The first application to be presented is ab (Apache benchmark), normally utilized in order to get hold of the performance values which the web server will be able to achieve. It is designed to give an impression of how your current Apache server works, specially by showing how many requests per second which is able to serve.
This tool puts forward multiple options, but the normal operation format so as to carry out performance tests will be as follows (there are other many useful options that you can check by going to the man):
[root@localhost ~]# ab -c concurrency -n request [-k] [http[s]://]hostname[:port]/path
Through the '-c' option is specified the number of multiple requests to perform at once, that is to say, it stands for the concurrence whereby the web server will be requested. For example, '-c 100' means that one hundred users will be launching requests simultaneously.
By means of the '-n' option, you may establish the number of requests to perform for the benchmarking session, that is, the total number of requests which will be run. For instance, '-c 20 -n 1000' means that 50 groups of 20 requests per group will be executed. And with the '-k' option, the HTTP keepalive feature is enabled. In this way, it is possible to handle multiple requests within one HTTP session.
[root@localhost ~]# ab -c 200 -n 1000 http://localhost/index.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Apache/2.2.15
Server Hostname: localhost
Server Port: 80
Document Path: /index.html
Document Length: 1656 bytes
Concurrency Level: 200
Time taken for tests: 1.696 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 1934625 bytes
HTML transferred: 1664280 bytes
Requests per second: 589.67 [#/sec] (mean)
Time per request: 339.175 [ms] (mean)
Time per request: 1.696 [ms] (mean, across all concurrent requests)
Transfer rate: 1114.05 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 8 10.0 4 38
Processing: 14 163 353.1 85 1645
Waiting: 11 160 353.2 81 1638
Total: 51 171 354.7 89 1660
Percentage of the requests served within a certain time (ms)
50% 89
66% 92
75% 94
80% 95
90% 102
95% 1637
98% 1645
99% 1651
100% 1660 (longest request)
The most important values output by ab are
Failed requests,
Requests per second and
Time per request. As you can distinguish in the above example, all requests have been completed successfully, with an average of 589 requests per second and an average time of 1.696 ms for each request.
Another interesting tool used to assess the performance of a web server is curl, which takes care of finding out the response time for an unique request of a single element. Curl transfers data from or to a server, by using one of the supported protocols (HTTP, HTTPS, FTP, etc.).
[root@localhost ~]# curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} http://localhost/index.html
0.002:0.003:0.004
In the preceding example, the time taken to process the request and start sending data has been 0.002 - 0.001 = 0.001 sg, and the time for sending 0.004 - 0.003 = 0.001 sg.
