How to test WordPress performance with ab – Apache HTTP server benchmarking tool ๐Ÿ—ฒ

1. Overview

The Apache HTTP server brings a great tool for stress testing your http server. You can have any http server being Nginx, Apache2, Node.js …

While there are many speed test sites out there, they have limited abilities to simulate different test conditions like number of requests at the same time and total number of requests in a row. Apache Benchmark is perfect to simulate different load scenarios and common sites like WordPress.

In order to demonstrate how to use Apache Benchmark (ab) we assume a configuration like this:

  • Apache httpd installed (brings us ab)
  • Server target under test: Rasbian + Nginx
  • Our http site: a simple WordPress setup with MariaDB

2. Quick Start into Apache Benchmark “ab

If you don’t have httpd installed and only want to use the auxiliary tools that come with it use apt to get the programs:

 apt-get install apache2-utils

Two important parameters will get us a long way, namely -c and -n

If you run ab without them, you will get a single request to an address that ends with a slash or a filename.

ab  https://www.mywordpressundertest.com/

3. Testing Scenarios

3.1 A single request (1×1)

The simplest scenario is a single hit to our WordPress site. This will give us a baseline to compare future results to. Note that multiple request to the same site will have lower “variable costs” since caching improves fetch times.

ab -c 1 -n 50 https://www.mywordpressundertest.com/

3.2 Multiple single requests in a row (1xN)

This is where concurrency is 1 and N is any number greater than 1. In other words, we have a scenario where user are lined up in a row and our server receives consecutive visitors.

ab -c 1 -n 50 https://www.mywordpressundertest.com/

3.3 Multiple requests at a time (Mx1)

A more realistic scenarios is to have multiple visitors at the same time. It is interesting to see how our server deals with this load. Especially when the concurrency gets high there might be some issues. Try 10, 100, 1000 even 10,000 and more.

ab -c 50 -n 50 https://www.mywordpressundertest.com/

3.4 Multiple requests at a time lined up (MxN)

The most realistic scenarios to have burst of visitors coming to our site in a certain time span. We adjust the n parameter to be a multiple of our concurrency parameter. While you should also increase the load to seen when your server succumbs to the load, the resulting load is more sensitive since the two parameters are “multiplied”.

ab -c 5 -n 50 https://www.mywordpressundertest.com/

6. Interpretation and Conclusion

The result might look like this:

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

Benchmarking www.pushcommit.com (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: www.pushcommit.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
TLS Server Name: www.pushcommit.com

Document Path: /
Document Length: 25971 bytes

Concurrency Level: 50
Time taken for tests: 26.889 seconds
Complete requests: 500
Failed requests: 0
Total transferred: 13145500 bytes
HTML transferred: 12985500 bytes
Requests per second: 18.60 [#/sec] (mean)
Time per request: 2688.868 [ms] (mean)
Time per request: 53.777 [ms] (mean, across all concurrent requests)
Transfer rate: 477.43 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 136 472 597.3 174 2438
Processing: 438 2118 691.0 2319 3236
Waiting: 390 2058 689.5 2258 3176
Total: 869 2591 426.1 2589 3921

Percentage of the requests served within a certain time (ms)
50% 2589
66% 2735
75% 2815
80% 2897
90% 3065
95% 3207
98% 3360
99% 3647
100% 3921 (longest request)

So we have 18.60 requests per second handled. Not bad for WordPress running on a Raspberry Pi B 3.

While it is easy to draw conclusions from relative results from our own server, we also want to compare it to other sites.
The simplest way to do this is to get a pick a popular site (let’s call it mypopularperformancesite.com) that is reliable and might give consistent performance:

ab -c 5 -n 50 https://www.mypopularperformancesite.com/

Be careful, since your requests might be interpreted as an attack. Don’t overdo it with your benchmark!

Moreover, you can set the -g gnuplot-file flag to get a file ready to be plotted or the -e csv-file to create comma separated values.

Even easier is the -w flag for html table output. You can put the result file right into your web-accessible directory or private cloud to have it available on the internet.

ab -c 5 -n 50 -w https://www.mypopularperformancesite.com/ > performance.html

There are also options for using user-password authentication, TLS selection, proxy, custom cookies and http header.

7. Outlook and Ideas

If you can afford to run a dedicated testing server (a Raspberry Pi might just be start) you could create a cron job that executes and checks ab results. Next, if the performance is insufficient an email notification is sent to you.

You might also test and optimize different scenarios:

  • Caching enabled / disabled
  • Different caching plugins
  • Reverse proxy caching
  • CDNs like cloudflare
  • SSL on / off
  • SSL /TLS cyphers
  • different target files and types
  • static vs dynamic content
  • 301 redirects (with / without “www.“)
  • … and many more

Leave a Reply

Your email address will not be published. Required fields are marked *