How to load test your websites with Apache Bench

How well are your websites performing? You might open a web browser, point it to those sites, and verify they’re working, but do you really take the time to load test those sites to see if they are living up to the high-performance standards your business (or clients) require? If you don’t know the answer to that question, you need to start load testing the sites you develop or administer.

Before you think this is challenging or will require paying for a third-party service, think again. There are plenty of tools to help you get this job done, many of them open-source and free. One such open-source tool is called Apache Bench.

Apache Bench is capable of load testing more than just the Apache web server, as any HTTP server or even an API (application programming interface) can be tested with this tool.

I want to show you how to both install Apache Bench and use it to load test a website. I’ll demonstrate it on Ubuntu 22.04, but it can be installed on just about any Linux distribution. Do know that Apache Bench is a command-line tool, but it’s actually pretty simple to use.

With that said, let’s get to work.

SEE: Hiring kit: Back-end Developer (TechRepublic Premium)

What you’ll need

To follow along, you’ll need a running instance of Ubuntu Linux. This can be either Ubuntu Server or Desktop and can be any release. You’ll also need a user with sudo privileges and a website to test.

How to install Apache Bench

The first thing we must do is install Apache Bench. Log into your instance of Ubuntu Linux, open a terminal window and issue the command:

sudo apt-get install apache2-utils -y

On the off-chance you’re using an RHEL-based distribution, such as Fedora Linux, that command would be:

sudo dnf install httpd-tools -y

The installation should go off without a hitch. Once it completes, you’re ready to load test a website.

How to load test with Apache Bench

The Apache Bench command does require a few options to run. The most often used options include:

• -n: The number of requests
• -c: The number of concurrent requests
• -H: Add header
• -r: Don’t exit on socket receive errors
• -k: Use the HTTP KeepAlive feature
• -p: File containing data to POST
• -t: The maximum time to spend benchmarking
• -T: Content-type header to use for POST/PUT data

A simple test would look something like this:

ab -n 1000 -c 100 http://SERVER/

Where SERVER is the domain or IP address of the server.

The trailing / is required, or the ab test will fail. Let’s say you have a development website you’re currently testing at IP address 192.168.1.11, and you want to run a simple ab load test. That command would be:

ab -n 1000 -c 100 http://192.168.1.11/

The results of that command might look something like this:

HTML transferred:   10918000 bytes

Requests per second: 292.16 [#/sec] (mean)

Time per request:   342.282 [ms] (mean)

Time per request:   3.423 [ms] (mean, across all concurrent requests)

Transfer rate:      3193.18 [Kbytes/sec] received

Connection Times (ms)

           min  mean[+/-sd] median   max

Connect:    8   30  16.6 29 274

Processing: 19  301 106.9 268 734

Waiting:    4  299 106.6 267 732

Total:     27  330 108.0 297 770

Percentage of the requests served within a certain time (ms)

  50% 297

  66% 312

  75% 322

  80% 329

  90% 544

  95% 635

  98% 718

  99% 747

 100% 770 (longest request)

Most of the output is fairly self-explanatory. The bottom half might need a bit of understanding. In the output you see above, 50% of the requests took 297 ms, 66% of the requests took 312 ms or less and so on. Something is clearly amiss with this site, as the response times should be faster.

Or, let’s say you have a specific site on a specific port you want to test. That command might look like this:

ab -n 1000 -c 100 http://192.168.1.11:9443/

If you also want to add the gzip and deflate headers into the mix as well as add KeepAlive and ensure the command doesn’t exit on a socket receive error, that command might look like this:

ab -n 1000 -c 100 -H “Accept-Encoding: gzip, deflate” -rk http://192.168.1.11/

All of a sudden you might see output that includes something like this:

Failed requests:    27

   (Connect: 0, Receive: 0, Length: 27, Exceptions: 0)

Let’s hit it a bit harder and limit the time to spend on the benchmarking with a command like this:

ab -t 60 -n 10000 -c 100 http://192.168.1.11/

This will take a bit longer because we’re hitting it with 10,000 requests and 100 concurrent requests.

And that’s pretty much all you need to load test your web servers from the command line. To learn more about what the ab command can do, make sure to read the man page with the man ab command.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.