How to run a stress test to your apache server in Ubuntu 18.04

For apache, exists the Apache Bench (ab) tool. This tool helps you measuring the performance of HTTP servers in a Linux environment, it works by generating a flood of requests (DoS kinda if your server isn't properly configured the amount of simultaneous requests ...) to a given URL and returns some easily digestible performance related metrics to the screen. This simplicity makes it appealing for running quick and dirty load tests, and a nice benefit to uncovering limits in your web stack or a service bottleneck that you did not anticipate. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serving. This tool helps you to basically know:

When will my application break (with how many users)?
What's your application average response time at a huge amount of simultaneous requests.
What is the maximum number of requests-per-second that my server can handle?

In this article, we'll explain you easily how to install AB on your Ubuntu distribution to test your apache server.

1. Install apache2-utils

In order to use the apache benchmark tool, we will need to install the apache2 utilities collection with the following command on your Ubuntu system:

sudo apt-get install apache2-utils

Note that this doesn't need to be installed on the same server where you want to run the test. You can install it even in your local desktop Ubuntu and run the test to a specific URL. This package provides additional tools that are useful for any web server. It includes:

ab: Apache benchmark tool (tool that we will use on this article)
fcgistarter: Start a FastCGI program
logresolve: Resolve IP addresses to hostnames in logfiles
htpasswd: Manipulate basic authentication files
htdigest: Manipulate digest authentication files
htdbm: Manipulate basic authentication files in DBM format, using APR
htcacheclean: Clean up the disk cache
rotatelogs: Periodically stop writing to a logfile and open a new one
split-logfile: Split a single log including multiple vhosts
checkgid: Checks whether the caller can setgid to the specified group
check_forensic: Extract mod_log_forensic output from Apache log files
httxt2dbm: Generate dbm files for use with RewriteMap

For more information about this tool, please visit the official website of apache here.

2. Running stress test

To put your server on stress to check how it behaves with a considerable amount of request, you can get started with the following command:

ab -c 100 -n 500 -r https://yourwebsite-or-ip.com/

Where:

-c: concurrency, the number of multiple requests to perform at a time. Default is one request at a time.
-n: requests, the number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.
-r: Don't exit on socket receive errors.
And as positional argument, the URL of your website with the specified module e.g / (for homepage).

In this case, our request will make simultaneously 100 requests/second at it will do 500 totally, so the test shouldn't take too long. On a decent server, this test shouldn't take down your server, so most of the servers out there should be able to handle this test, however you can start changing values to make your server sweat:

# 200 simultaneous request should start to be heavy for your server, making 5K requests in total
ab -c 200 -n 5000 -r https://yourwebsite-or-ip.com/

When you have DoS/DDoS protection in apache, for example with the usage of the qos_module, you will see that there will be a lot of failed requests in the output of the command. This happens, because the protection is indeed working and as mentioned, the ab tool basically floods your server with requests, so a lot of requests with the same IP will automatically be blocked by the apache module.

If you want to test fully without failed requests, you may disable for a short lapse of time the protection of the qos module in your server, but don't forget to enable it once you are done with the test. You won't be able to test at its maximum your server resources if only a quarter of them are arriving succesfully to your server.

Happy coding !