Last updated February 16, 2016. Created on August 17, 2006.
Edited by TheodorosPloumis, YesCT, mlncn, grendzy. Log in to edit this page.

When attempting to create a large change in Drupal core, or even during the course of developing Drupal sites for clients, often you are asked to provide benchmark results to ensure that your change doesn't negatively impact performance (or to see how much it improves performance). This document will talk about the various strategies involved in benchmarking Drupal code.

Tools of the trade

This document will discuss the ab tool in depth. Its a free, open source performance testing solution that comes with Apache and therefore is the tool that is most commonly used in the community.

Before benchmarking, you'll need a local development environment. See Getting Involved guide for an overview, Setting up an environment for general tools the community uses, and Contribute to development for tips on how to contribute code more generally.

Other profiling resources

Looking for support? Visit the forums, or join #drupal-support in IRC.


ednique’s picture

Just a point...
You should run ab on another server to get real results...
Preferably a server from another network...

Next it would be better to use the -c (clients)...

specifying -n 100 will do 100 requests after each other. Like one person hitting a 100 times the reload button.
specifying -n 100 -c 10 will do 10 times 10 request at the same time. Like 10 persons hitting 10 times on reload.

I usually do thses tests:
-n 100 -c 10
-n 1000 -c 10
-n 1000 -c 50

This will give you a better overview of the ratings...

The most important output is
failed requests: hopefully not too many. zero is perfect
requests per second: the higher the better (look at the difference for this value if you call ab on the same server compared to a remote server)
Time per request: The lower the better (put in mind that after 3 seconds your visitors go away...)

I found a great doc about performance tuning that uses ab as example for validating...
It's mainly about Perl but the "Performance tuning by tweaking Apache Configuration" is helpfull for php people too...

Tali’s picture


Actually the author is correct, you want to run ab from localhost in this case. You aren't trying to benchmark the server per se, you are (in this case) trying to benchmark the code. Seeing as how network latency is far greater and less predictable for each run than CPU cycles are, you would have the greatest margin or error and the least accurate results from running from a remote server.

Benchmarking code - run from localhost
Benchmarking apache server - run from remote host

jsware’s picture

IMHO, even when benchmarking the server, one should do it on local network instead.

When benchmarking the webapp or server directly on localhost, the "benchmarkee" shares the processor(s) and HDD with "benchmarker".

When benchmarking the webapp or apache server remotely (not on local network), the results may be biased by connection limitation. E.g. if the average node has say 20k in all its files, then 50 requests/sec would require 1MBps stream, which would be pretty small on local network but quite intense to do it on the internet.

Timberwoofie’s picture

Vastly easier than mucking about with CS, just download and install the Devel module in your test server. The Devel module makes it fast and easy to add lots of content to your Drupal server. Once installed ...
Administer > Site Building > Blocks
Devel: right sidebar
Devel Node Access: content

Administer > Site Configuration > Devel
check Collect query info
check Display query log (shows queries for the page at the bottom of the page)
sort query log by duration
check Store executed queries (needed for the Database queries log to work)
check Display page timer
check Display memory usage
click Save Configuration

Administer > Content Management > Generate Categories
15 vocabularies
250 terms
12 max word length
click Do it!

Administer > Content Management > Generate Content
5000 nodes
8 max title words
click Do it!

Now you can run the benchmarks.

itkovian’s picture

I am wondering how sensitive these timing results are to the populating of the databse the Devel module does. Has anybody any results on that?

Second, I think it would be better if ab gave a confidence interval for the mean response time, instead of just the mean and standard deviation. Obviously you could compute this yourself, but still ...

Ian Ward’s picture

When you use ab I believe you need to specify the -C flag and a session/cookie name/value pair, otherwise you could end up benchmarking the 403 access denied page, if the page you'd like to benchmark is behind Drupal access control, as opposed to available for the anonymous visitor, or if any of the content on the page is not available to the anonymous user.

Development Seed Blog

moshe weitzman’s picture

ab reports the http status code so you would see 403 in this case. but yeah, if you need to authenticate to benchmark an admin page or something, then -c is perfect.

dgtlmoon’s picture

Heres something i wrote on using the shell to quickly analyze your mysql logs, good for seeing which modules are hitting the server the most

blundeln’s picture

I use an application called mtop, which is very handy for quickly seeing which queries are taking the most time. This has been a big help for my Drupal development.

See here for details:

Oxego777’s picture

Yes, thats a good and useful tool to check database queries.

Marcelino’s picture

Yes this app is great. Wanted this to check db queries