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|
|Other||Privileged access to your Linux system as root or via the |
|Conventions|| # - requires given linux commands to be executed with root privileges either directly as a root user or by use of |
How to install Apache BenchApache 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-utilsFor CentOS/RHEL execute:
# dnf install httpd-tools
The UAF Geophysical Institute, is looking for an experienced Linux Systems Analyst to join their team of research cyber infrastructure analysts and engineers. LOCATION: Fairbanks, Alaska, USA
How to use Apache BenchUse Apache Bench with the ab command. The most basic syntax is:
$ ab hostname/
abrequires the trailing slash on the hostname/IP address.
- -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
$ 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.
ConsiderationsThere 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 outerror, 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 resultsWhen 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 resultsThe 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.
Time taken for testsline.
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 requestvalue 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 7373Connect 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 timesreport less alarming. 90% of our HTTP requests were handled in less than half a second.