Prerequisites

• A fresh Webdock cloud Ubuntu instance with LAMP or LEMP installed (your target web server)
• You have shell (SSH) access to a VPS which will be your source web server.

Choosing Source / Target

What you will be doing below is sending a lot of requests to your target web server running your website or application and gauging how many pageviews it can deliver and how quickly. In order to get an accurate test you should preferably run ApacheBench from a seperate server (your source) located in a region close to your target so that you do not run into bandwidth bottlenecks before you actually hit any real bottleneck on your target system.

So unless you have a really good internet connection (1 Gigabit or better)  your source server should be in the cloud - preferably in the same datacenter as your target server - in order to eliminate any network or latency bottlenecks / noise in your resulting data.

Important: You should only run ApacheBench against your own servers or you can get into trouble. Sending lots and lots of request to a website could be interpreted as a DOS attack and can (best case) get your IP blocked from visiting that site again.

Install ApacheBench

In order to use ApacheBench tool, you will need to install the apache2 utility package on the system which will be performing all the requests to your target system.

You can install it on your Webdock server or local desktop system by just running the following command:

apt-get install apache2-utils -y

Once the installation is completed, you can verify the ApacheBench Installation using the following command:

ab -V

You should get output similar to the following:

This is ApacheBench, Version 2.3 <$Revision: 1874286 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

You don't need to install this tool on the webserver where you want to run the test against (your target). You can also install it on your local desktop system if you are running Linux and have a really good internet connection (see above) and run the test against you web server URL.

The Apache utils package provides some additional tools that may be useful for a web server.

• ab : The tool described here which is used for benchmarking your web server.
• htpasswd : Used to store usernames and password for basic authentication of HTTP users.
• htdigest : Used to create and update password file which is used by Apache HTTPD digest authentication.
• htdbm : Used to manipulate the DBM format files used to store usernames and password for basic authentication of HTTP users.
• fcgistarter : Start a FastCGI program.
• htcacheclean : Used to cleanup the mod_disk_cache.
• httxt2dbm : Used to generate dbm files from text input, for use in RewriteMap with the dbm map type.
• logresolve : Resolve IP addresses to hostnames in logfiles.

Benchmarking Web Server Using a Single Connection

ApacheBench allows you to configure the number of requests to send, a timeout limit, number of multiple requests to perform at a time and request headers.

The basic syntax to run an ApacheBench command is as shown below:

ab [OPTIONS] [WEB-SERVER-ADDRESS-URL]

The most commonly used options are:

• -n : Number of requests to perform for the benchmarking session. The default is to just perform a single request.
• -c : Number of multiple requests to perform at a time. Default is one request at a time.
• -t : Maximum number of seconds to spend for benchmarking.
• -r : Don't exit on socket receive errors.
• -k : Perform multiple requests within one HTTP session.
• -A : You can use the authentication credentials to test the target web server (http basic auth).

Run the Apache Bench command on a Webdock instance or your local system without any options to benchmark your target web server using a single connection:

ab http://your-web-server-ip-or-address/

Note: Always provide the web server address followed by a /. URLs without the trailing / will cause Apachebench to return an error.

The above command will make a single connection request to your web server. After performing the test, you should get something like the following output:

This is ApacheBench, Version 2.3 <$Revision: 1874286 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 45.148.28.82 (be patient).....done


Server Software:        Apache
Server Hostname:        45.148.28.82
Server Port:            80

Document Path:          /
Document Length:        29832 bytes

Concurrency Level:      1
Time taken for tests:   0.002 seconds
Complete requests:      1
Failed requests:        0
Total transferred:      29986 bytes
HTML transferred:       29832 bytes
Requests per second:    438.79 [#/sec] (mean)
Time per request:       2.279 [ms] (mean)
Time per request:       2.279 [ms] (mean, across all concurrent requests)
Transfer rate:          12849.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     2    2   0.0      2       2
Waiting:        2    2   0.0      2       2
Total:          2    2   0.0      2       2

As you can see, our web server has handled 438.79 requests per second, and it took a total 0.002 seconds to serve a single request.

A brief explanation of each output value is shown below:

• Server Software : Returns the HTTP header with the name of the web server.
• Server Hostname : Returns the DNS or IP address given on the command line.
• Server Port : The port to which ab is connecting. If no port is given on the command line, this will default to 80 for http and 443 for https.
• Document Path : This is the request URI parsed from the command line string.
• Document Length : The size in bytes of the first successfully returned document.
• Concurrency Level : The number of concurrent clients used during the test.
• Time taken for tests : Total time taken to perform the test.
• Complete requests : Total number of successful responses received.
• Failed requests : Total number of failed requests.
• Total transferred : Total number of bytes received from the web server.
• HTML transferred : Total number of document bytes received from the server.
• Requests per second : Total number of requests per second.
• Time per request : This is the average time spent per request.
• Transfer rate : The rate of transfer as calculated by the formula totalread / 1024 / timetaken.

Benchmarking Web Server Using Multiple Connections

The more useful test is to start stressing the webserver with many requests and see where it starts to max out, stall or even return errors as it is getting overloaded. In this section we will test a web server by performing 500 requests total with a concurrency of 100 requests at a time.

Before starting, make sure that the host conducting the ApacheBench test has enough memory available to store the state of each connection and enough CPU resources to make all TCP connections - this can be hard to gauge beforehand but if you experience errors running ApacheBench this is something to look out for.

You can run the following command to benchmark the web server:

ab -n 500 -c 100 http://your-server-server-ip-or-address/

This command will send 100 requests simultaneously and will do this 5 times for a total of 500 requests.

This is ApacheBench, Version 2.3 <$Revision: 1874286 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 45.148.28.82 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests


Server Software:        Apache
Server Hostname:        45.148.28.82
Server Port:            80

Document Path:          /
Document Length:        29832 bytes

Concurrency Level:      100
Time taken for tests:   0.061 seconds
Complete requests:      500
Failed requests:        0
Total transferred:      14993000 bytes
HTML transferred:       14916000 bytes
Requests per second:    8151.95 [#/sec] (mean)
Time per request:       12.267 [ms] (mean)
Time per request:       0.123 [ms] (mean, across all concurrent requests)
Transfer rate:          238715.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.2      1       4
Processing:     2   10   2.8     10      20
Waiting:        1    9   2.8      8      18
Total:          6   11   2.6     10      20

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     13
  90%     14
  95%     15
  98%     18
  99%     18
 100%     20 (longest request)

As you can see, Apache has handled 8151.95 requests per second, and it took a total 0.061 seconds to serve all the requests. You should not take this number as something you should try and strive for in your web application as here we are just requesting a static HTML file. Nginx and Apache are very good at serving static files and can do so at an extremely rapid clip.

Interpreting Results

While benchmarking your target web server it is a good idea to have a seperate console window open and running something like htop or similar tool which gives you an overview of what your target web server system is doing. If you for example experience that when doing lots of simultaneous requests against your php application you notice RAM filling up to 100% and then the request speed taking a nosedive, this is a good indication of where that specific VPS instance has a bottleneck. If you want to serve more requests faster, you would need more RAM or optimize your application to use less memory

The same goes if you notice you hit 100% CPU utilization and your request speed starts stalling, then you need to gauge whether the instance you have has enough horsepower for the expected load / number of visitors to your site or whether you need to upgrade your instance in order to give yourself more headroom.

Interpreting results can be a bit tricky as it all depends on how many visitors you want to be able to serve, how well optimized your application is as well as the built-in limits of your VPS.

Other Third Party Tools

There are lots of third party tools available to test web server performance like, GTMetrix, Google Pagespeed etc. - What these tools have in common is that they are not testing the throughput of your server but instead they make a single (or very few) requests and just look at TTFB (Time To First Byte) and then mainly focus on how quickly the site renders in your browser.

These tools won't really tell you much about the quality of your VPS, rather they will tell you a lot more about how well structured and built your website is and how well you leverage caching and CDN, minification etc. etc.

Among the most popular 3rd party "front end" testing tools are:

GTmetrix

GTmetrix is one of the most popular free tools for testing your web server performance. This tool will help identify what is slowing down your site and how to fix those issues. It uses a combination of Google PageSpeed Insights and YSlow to generate scores and recommendations.

Google PageSpeed

Google PageSpeed is another handy tool that can be used to analyzes your site's front-end performance and offers optimization suggestions. When you test your website performance with Google PageSpeed, it will return different sections and indicators about the performance of that page including, Speed score, Field data, Lab data, Opportunities, Diagnostics and Passed audits. Google PageSpeed is popular for its three main features:

• Speed Score : It gives you an indication of how well your website performs.
• Color Scheme : It provides suggestions in three color green check, orange circle and red triangle. That makes it easier to identify priority issues affecting your website performance.
• Recommendations : This will help you to find what you should fix on your site to improve its performance.

Both tools are useful for people who want to optimize their pages after they have been sent out from the webserver and have hit the user browser. There are however issues with both tools in that they are very bad at giving you instructions on how to solve the problems they might report. 

Conclusion

In this tutorial, we gave you a primer on how to install Apache Bench and how to use it with different options in order to test the performance of your website. We hope this can get you started on getting a baseline idea on how well your VPS and website performs and given you a powerful tool to make baseline comparisons between VPS providers.