How to load-test web server using ApacheBench (ab)
Load testing a web server is crucial for assessing how the server behaves under a particular load, especially before deploying it in a live environment. ApacheBench, commonly known as ab, is a widely used tool for load testing HTTP servers. It provides a simple way to create a large number of requests and calculate the number of requests served per second, latency, and other related metrics.
ApacheBench comes pre-installed on many UNIX-based systems and is part of the Apache HTTP server package. It's lightweight, easy to use, and customizable according to the requirements of the test. It helps in pinpointing potential bottlenecks, ensuring that your web server can handle the expected number of simultaneous connections.
Whether you're using Apache, Nginx, or any other HTTP server, ApacheBench can be used to conduct rigorous testing. You can iteratively run the test and consequently tune your webserver configuration.
Steps to load-test web server using ab:
-
Ensure that ApacheBench is installed on your system.
$ ab -V This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Install apache2-utils if ab is not installed.
$ sudo apt update && sudo apt install --assume-yes apache2-utils # Ubuntu and Debian derivatives $ sudo yum install --assumeyes httpd-tools # CentOS and RedHat derivatives
-
Get the URL of the web page you want to perform the load test against.
-
Run ab against the selected web page.
$ ab -n 1000 -c 10 https://www.example.com/
Request format: ab -n <number_of_request> -c <concurrency>.
This is a basic example of performing a performance test which in this case is to send a total of 1000 requests to the web server with 10 requests being sent concurrently.Make sure to add a (forward) slash (/) at the end of the URL otherwise it will not be recognised by the command
-
Analyze the output to understand the performance metrics.
$ ab -n 1000 -c 10 https://www.example.com/ This is ApacheBench, Version 2.3 <$Revision: 1826891 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.example.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 560 requests Completed 610 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Apache/2.4.33 Server Hostname: www.example.com Server Port: 443 Document Path: / Document Length: 12906 bytes Concurrency Level: 10 Time taken for tests: 19.070 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 13410000 bytes HTML transferred: 12905610 bytes Requests per second: 52.44 [#/sec] (mean) Time per request: 190.704 [ms] (mean) Time per request: 19.070 [ms] (mean, across all concurrent requests) Transfer rate: 686.70 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 73 190 41.2 186 348 Waiting: 72 188 41.2 185 346 Total: 73 190 41.2 186 348 Percentage of the requests served within a certain time (ms) 50% 186 66% 207 75% 218 80% 226 90% 244 95% 257 98% 272 99% 305 100% 348 (longest request)
The key metrics to look at include Requests per second, Time per request, and possible Failed requests.
-
Test enabling KeepAlive mode and reduces network overhead by sharing a single HTTP session for all the requests.
$ ab -n 1000 -c 10 -k https://www.example.com/
-
Try different concurrency levels, request numbers, or use additional options like POST data testing or custom HTTP headers to simulate different scenarios.
Other options for ab:
$ ab -h Usage: ab [options] [http[s]://]hostname[:port]/path Options are: -n requests Number of requests to perform -c concurrency Number of multiple requests to make at a time -t timelimit Seconds to max. to spend on benchmarking This implies -n 50000 -s timeout Seconds to max. wait for each response Default is 30 seconds -b windowsize Size of TCP send/receive buffer, in bytes -B address Address to bind to when making outgoing connections -p postfile File containing data to POST. Remember also to set -T -u putfile File containing data to PUT. Remember also to set -T -T content-type Content-type header to use for POST/PUT data, eg. 'application/x-www-form-urlencoded' Default is 'text/plain' -v verbosity How much troubleshooting info to print -w Print out results in HTML tables -i Use HEAD instead of GET -x attributes String to insert as table attributes -y attributes String to insert as tr attributes -z attributes String to insert as td or th attributes -C attribute Add cookie, eg. 'Apache=1234'. (repeatable) -H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip' Inserted after all normal header lines. (repeatable) -A attribute Add Basic WWW Authentication, the attributes are a colon separated username and password. -P attribute Add Basic Proxy Authentication, the attributes are a colon separated username and password. -X proxy:port Proxyserver and port number to use -V Print version number and exit -k Use HTTP KeepAlive feature -d Do not show percentiles served table. -S Do not show confidence estimators and warnings. -q Do not show progress when doing more than 150 requests -l Accept variable document length (use this for dynamic pages) -g filename Output collected data to gnuplot format file. -e filename Output CSV file with percentages served -r Don't exit on socket receive errors. -m method Method name -h Display usage information (this message) -I Disable TLS Server Name Indication (SNI) extension -Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers) -f protocol Specify SSL/TLS protocol (SSL2, TLS1, TLS1.1, TLS1.2 or ALL) -E certfile Specify optional client certificate chain and private key
-
Review and interpret the results to assess the server's behavior under load, and identify any bottlenecks and potential areas for improvement.
Tips for load-testing web server using ab:
-
This is by no means mimic real-world usage. Other tools such as Apache's JMeter might be more suitable for that.
-
ab should not be run on the same machine as the webserver. ab is resource-intensive; thus, doing so will negatively impact the web server's performance and skew the test result.
-
Various factors could improve the server's performance. It's best to run multiple tests and average the result.