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.

Step-by-step video guide:

Steps to load-test web server using ab:

  1. 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
  2. Get the URL of the web page you want to perform the load test against.
  3. 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

  4. 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.

  5. 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/
  6. 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
  7. 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:

  1. This is by no means mimic real-world usage. Other tools such as Apache's JMeter might be more suitable for that.
  2. 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.
  3. Various factors could improve the server's performance. It's best to run multiple tests and average the result.
Discuss the article:

Comment anonymously. Login not required.