Skip to main content

Drupal Reverse Proxy Performance Benchmark - HudHost Edge Cache

In this article I aim to illustrate the performance boost achieved from a production Drupal site with our Edge Cache enabled. That means the tests below are performed on our optimised hosting stack with Drupal cache and file aggregation enabled - just like they would be on any production site.

This is not a benchtest of Drupal itself. I’m testing the HudHost Edge Cache, which is an advanced Nginx Reverse Proxy that's configured specifically for Drupal websites.

This offers a huge performance boost by caching your Drupal site pages; so subsequent visitors receive responses directly from memory without hitting your Drupal theme, modules and database, etc.

Our Edge Cache offers the additional wow-whiz of being configurable on all our hosting accounts with 1 click.

So, to the test!

To give an overall feel of the Edge Cache's performance, I'll be running the same test on 2 different Drupal 7 sites:

Site 1 - Vanilla Drupal 7:
A new 1-click install from our control panel with development modules disabled and caching enabled (because this is a production test!). This gives a baseline of performance for Drupal 7 on our platform.

Site 2 - Typical Drupal Site:
HudHost.com - Our main HudHost site seems a good candidate for a typical Drupal site that contains images, views and other common modules.

Test Methodology:

I'm using Apache Benchtest to generate the load with the following options:

  • - n 10000 (10,000 request sent to the server)
  • - c 100 (100 concurrent requests, which is large by any standard)
  • - H -H 'Accept-Encoding: gzip,deflate' (The only header I'm sending is accept deflate as our servers compress (gzip) static files and HTML before transmission)

I've run each test 3 times to be sure that the results shown below are repeatable. The test results shown are not averages across 3 tests, I’ve just selected the first one.
Tests were run from a server on the same local network in order to eliminate latency and just expose pure server/application response times.

Please don't try this at home, folks

Our DDOS security would block this sort of test from outside of our network, so I'm afraid you can't run this test and hammer our servers without letting us know first. Which seems fair. So, please do try this at home, just don't attack our servers while doing it. :-)

Test 1 - Vanilla Drupal

Optimised Stack - No Edge Cache

Document Length:        2184 bytes

Concurrency Level:      50
Time taken for tests:   13.222 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26060000 bytes
HTML transferred:       21840000 bytes
Requests per second:    756.29 [#/sec] (mean)
Time per request:       66.112 [ms] (mean)
Time per request:       1.322 [ms] (mean, across all concurrent requests)
Transfer rate:          1924.71 [Kbytes/sec] received

Optimised Stack - With Edge Cache

Document Length:        2184 bytes

Concurrency Level:      100
Time taken for tests:   2.452 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      25901460 bytes
HTML transferred:       21841054 bytes
Requests per second:    4077.71 [#/sec] (mean)
Time per request:       24.524 [ms] (mean)
Time per request:       0.245 [ms] (mean, across all concurrent requests)
Transfer rate:          10314.33 [Kbytes/sec] received

Test 2 - Small Drupal Site: HudHosting.com

Optimised Stack - No Edge Cache

Document Length:        4838 bytes

Concurrency Level:      100
Time taken for tests:   13.764 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      53640000 bytes
HTML transferred:       48380000 bytes
Requests per second:    726.53 [#/sec] (mean)
Time per request:       137.640 [ms] (mean)
Time per request:       1.376 [ms] (mean, across all concurrent requests)
Transfer rate:          3805.77 [Kbytes/sec] received

Optimised Stack - With Edge Cache

Document Length:        4838 bytes

Concurrency Level:      100
Time taken for tests:   4.741 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      53480000 bytes
HTML transferred:       48380000 bytes
Requests per second:    2109.32 [#/sec] (mean)
Time per request:       47.409 [ms] (mean)
Time per request:       0.474 [ms] (mean, across all concurrent requests)
Transfer rate:          11016.24 [Kbytes/sec] received

Observations

The great news is that all tests with Edge Cache enabled maxed out the 100mbit/s connection, which is exactly what you want! Each hosting account on our platform (like most others) is limited to 100mbit/s. I'd argue, if you're using more than that, either something is wrong or you've outgrown even our hosting plans! I have corporate consulting clients with $1.5million+ online revenue a day using less bandwidth ;-)

The two really interesting numbers from these tests, as with any other Apache Bench test is the Requests per second and the Time per Requests. In the non-Edge Cache enabled tests the Requests per second were between 726/second and 756/second with Time per request of around 66ms and 137ms respectively. Those are very decent numbers by any standard for Drupal sites.

I'm fairly stoked with what happens when I enable Edge Caches with 1 click. The Requests per second go through the roof to 4077/second for the Vanilla Drupal 7 site with few images and still an amazing 2109/second for our typical production Drupal site with contrib modules and images.

For me, it's the Time per request when Edge Cache is enabled that's most rewarding to see. Just 24ms for the Vanilla Drupal 7 site and still a blisteringly fast 47ms for our HudHost Drupal 7 site. Anything under 150ms response time can be considered very reasonable and sub 100ms really is a great result. To achieve half that again for our real world test site is definitely a cause for a round of beers at the next Drupal meet up.