Apache Bench is a tool used to measure the performance of a web server. Despite having “Apache” in its name, it can actually be used to test any type of web server. In this tutorial, we’ll go over the steps to use Apache Bench and how to interpret its report about a web server’s performance.
Apache Bench works by sending varying amounts of HTTP requests to the web server and recording the response times. It can tell you how much congestion the server can handle before it gets overwhelmed and performance diminishes.
In this tutorial you will learn:
- How to install Apache Bench
- How to use Apache Bench
- How to interpret Apache Bench Results
Software Requirements and Conventions Used
| Category | Requirements, Conventions or Software Version Used |
|---|---|
| System | Any GNU/Linux Distribution |
| Software | ab |
| Other | Privileged access to your Linux system as root or via the sudo command. |
| Conventions |
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command$ – requires given linux commands to be executed as a regular non-privileged user |
How to install Apache Bench
Apache Bench is part of the apache2-utils package, which can be installed with your system’s package manager.
For Ubuntu and other Debian-based distributions, use the apt-get command to install it:
$ sudo apt-get install apache2-utils
For CentOS/RHEL execute:
# dnf install httpd-tools
How to use Apache Bench
Use Apache Bench with the ab command. The most basic syntax is:
$ ab hostname/
ab requires the trailing slash on the hostname/IP address.This basic command isn’t particularly useful without any additional options, so let’s include some. Apache Bench has a lot of options available, but some of the most useful are:
- -n (number): used to specify the number of requests ab should send to apache
- -t (timeout): used to specify (in seconds) how long ab should continue sending requests
- -c (concurrent): used to specify the number of simultaneous requests for ab to make
You can play around with these options in order to simulate more realistic traffic for your web server, and observe how it performs under various amounts of stress.
$ ab -t 10 -n 10000 -c 100 hostname/
This command will benchmark our web server for 10 seconds, sending a maximum of 10,000 total requests, and send 100 of those requests concurrently.
Considerations
There are a few things to consider when using Apache Bench. When a server receives thousands of HTTP requests from a single source in a matter of seconds, a lot of firewalls are going to interpret that as a denial of service attack and attempt to block repeated connections for a while.
We would only recommend using Apache Bench on a local network, and test against hosts that you control. Still, this isn’t a perfect simulation of actual traffic.
When connecting to a web server somewhere in the world, users will have varying levels of latency and hops (the route their connection takes to the web server), which play major roles in the perceived speed of your website.
Furthermore, your test machine (the system from which you are running the ab command) could be a bottleneck. If you suspect that your system doesn’t have the resources required to initiate this large number of connections, you can verify by using the top command to monitor CPU and memory usage while ab is performing its test.
If you get a Connection timed out error, your connections probably got blocked by a firewall or the Apache server got overwhelmed and wasn’t able to handle further requests.
Apache Bench test results
When Apache Bench finishes running its test, it will output the results to the terminal, and should look something like this:
Finished 882 requests
Server Software: Apache/2.4.29
Server Hostname: ---
Server Port: 80
Document Path: /
Document Length: 4878 bytes
Concurrency Level: 100
Time taken for tests: 10.008 seconds
Complete requests: 882
Failed requests: 0
Total transferred: 4480560 bytes
HTML transferred: 4302396 bytes
Requests per second: 88.13 [#/sec] (mean)
Time per request: 1134.700 [ms] (mean)
Time per request: 11.347 [ms] (mean, across all concurrent requests)
Transfer rate: 437.20 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 77 327 1008.3 89 7240
Processing: 87 115 43.4 101 807
Waiting: 86 112 39.1 100 604
Total: 168 442 1009.1 192 7373
Percentage of the requests served within a certain time (ms)
50% 192
66% 202
75% 224
80% 268
90% 428
95% 1207
98% 3208
99% 7345
100% 7373 (longest request)
Interpreting Apache Bench results
The output above contains all the necessary information; you just need to know what these various metrics mean in order to make sense of the results. We’ll go over all of them in this section.
The first few lines just give general information about the web server. The helpful information really starts with the Time taken for tests line.
Time taken for tests reports how long the ab command took to complete its test. Since we specified -n 10 in our ab command, this line is obviously going to report that the test took 10 seconds. If we hadn’t specified a timeout, this line will tell you how long it took to finish sending the specified number of requests. After applying optimizations to your web server, you should see a decrease in the time taken for tests to complete (when not specifying a timeout).
Complete requests reports how many of the requests were sent and returned successfully.
Failed requests reports how many of the requests were unable to complete. You’ll obviously want to see a very small number, ideally zero. If this row does report some failed requests, it could indicate that the web server was overwhelmed and unable to respond to all requests in time.
Total transferred and HTML transferred rows report how much data, in bytes, was sent to the web server.
Requests per second is the average of how many requests the web server was able to handle in a second. It’s useful in determining how your web server will perform when many users are logging onto it at the same time.
Time per request is how much time, on average, it took to process a request. The values are given in milliseconds, so in our example output the time was 1.1 seconds. The second time per request value is simply multiplied by the concurrency value.
Transfer rate is how fast it was able to transfer the data, which shouldn’t pose any kind of a bottleneck on a local network. If testing over the internet, the routing and bandwidth limitations could affect this value long before Apache itself.
The Connection Times (ms) section lists response times for different stages of the HTTP requests.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 77 327 1008.3 89 7240
Processing: 87 115 43.4 101 807
Waiting: 86 112 39.1 100 604
Total: 168 442 1009.1 192 7373
Connect indicates how much time it took ab to establish a connection with the web server.
Processing is the amount of time that Apache spent processing the requests. Since ab can’t actually measure this, it just records the amount of time a connection is open after being initiated.
Waiting is how long ab has to wait between sending a request and receiving a response from the web server.
Total indicates the total time elapsed from initiating a connection to the server, receiving a response, and finally closing the connection.
Apache Bench’s last metric offers a more precise look at the average response time of the web server by sorting connection times into percentiles.
Percentage of the requests served within a certain time (ms) 50% 192 66% 202 75% 224 80% 268 90% 428 95% 1207 98% 3208 99% 7345 100% 7373 (longest request)
In our example output above, 50% of the HTTP requests were handled and closed in only 192 ms or less. This report also indicates that the responses taking 7 seconds (there are only two of them) are outliers, making the connection times report less alarming. 90% of our HTTP requests were handled in less than half a second.
Conclusion
In this article we saw how to install Apache Bench and use it to test the performance of a web server. We also learned how to interpret the output from Apache Bench, allowing us to determine where the bottlenecks lie. After optimizing your web server further, run Apache Bench again and expect to see better performance results, if there has indeed been improvements made.
