Skip to main content

Quick Drupal performance test: The Boost module makes a huge difference

Posted in

I have been playing with the Boost module a bit today. Boost is a nifty caching module that can vastly increase your website's performance when most of your visitors are anonymous users. So, how does Boost work? Basically, whenever an anonymous user requests a page, that page is not only delivered to the user, but also stored in a file. When a second anonymous user requests the same page again (within a given time), the webserver does not even bother to boot Drupal, but will just deliver the cached file instead.
Obviously, serving static HTML saves you a lot of time. All your webserver has to do is to copy bytes from a filestream to a network socket. No need to parse program code, no need to perform database queries.

Naturally, when you do performance tweaks, you are also interested in measuring performance with and without the tweak for doing a before and afterwards comparison. My personal before and afterwards experience can pretty much be described by one word: Impressive!

Now, I should note that I did not bother to setup proper testing conditions, as I was only interested in seeing the difference, the Boost module would make for my site. My results are far from scientific and should only be seen as a rough ballpark figure of what order of improvement could be hoped for. The reason for publishing my findings anyway is to give people who are unable to do their own benchmarks or undecided whether or not to use boost a first impression.

So, how do you measure webserver performance? Thats actually quite easy! The apache webserver comes with a benchmarking tool, called "ab". The "ab" tool will simply request an URL for an arbitrary number of times, using an equally arbitrary amount of concurrency. For my tests, I chose to request the frontpage of my website 1000 times, using 10 simultaneous requests.

The command for doing this is as follows:

ab -n 1000 -c 10 http://www.test-your-own-webserver.com/

To get it as stressful as possible, I ran the program on the server directly, so no network lag would give the server the chance to catch it's breath. Note, that those

Ok, first the results for not having the Boost module enabled:


Benchmarking www.onyxbits.de (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software: Apache
Server Hostname: www.onyxbits.de
Server Port: 80

Document Path: /
Document Length: 30225 bytes

Concurrency Level: 10
Time taken for tests: 391.576237 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 30707000 bytes
HTML transferred: 30225000 bytes
Requests per second: 2.55 [#/sec] (mean)
Time per request: 3915.762 [ms] (mean)
Time per request: 391.576 [ms] (mean, across all concurrent requests)
Transfer rate: 76.58 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 7
Processing: 1339 3909 1762.8 3601 11919
Waiting: 1248 3705 1722.9 3379 11606
Total: 1339 3909 1762.8 3601 11919

Percentage of the requests served within a certain time (ms)
50% 3601
66% 4398
75% 4957
80% 5321
90% 6253
95% 7161
98% 8279
99% 9544
100% 11919 (longest request)

And now with the Boost module enabled. The difference is quite significant!


Benchmarking www.onyxbits.de (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software: Apache
Server Hostname: www.onyxbits.de
Server Port: 80

Document Path: /
Document Length: 30309 bytes

Concurrency Level: 10
Time taken for tests: 1.61708 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 30766410 bytes
HTML transferred: 30369618 bytes
Requests per second: 941.88 [#/sec] (mean)
Time per request: 10.617 [ms] (mean)
Time per request: 1.062 [ms] (mean, across all concurrent requests)
Transfer rate: 28298.74 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.7 2 8
Processing: 1 7 3.4 8 74
Waiting: 0 3 3.0 3 68
Total: 2 9 3.6 9 77

Percentage of the requests served within a certain time (ms)
50% 9
66% 10
75% 11
80% 11
90% 13
95% 14
98% 16
99% 17
100% 77 (longest request

Going down from 11 seconds to 77 milliseconds in the worst case is quite a substantial improvement, isn't it? The overall improvement of six minutes(!) down to just about two seconds is due to congestion. Drupal requires a lot of RAM and CPU cycles. Requests always allocate resources on the server and as long as requests are not completed, their resources stay reserved, so new requests have to be postponed.
In other words: The Boost module not only speeds up page serving, it also allows the webserver to answer way more requests than it would normally be able to do.

Of course, the Boost module has one big disadvantage: since it is designed to bypass loading Drupal whenever possible, you are inevitably messing up Drupals node counter and have to rely on external statistics tools to measure your site's popularity (unless, of course, you enable Boost's stat block, but since this loads Drupal again, it more or less defeats the purpose of using the module in the first place).