Drupal performance testing with Siege

Why Siege?

So far, it's the simplest tool I've found to quickly benchmark response times. When I'm developing or tuning web/db servers, I want to quickly get a idea of the performance impact my changes are making. Tools like JMeter offer quite a bit more, but I appreciate the low barrier to entry for a tool like Siege. It's perfect when you just need to know if you're making performance better or worse, and Firebug isn't making it obvious. I should also note that it is very similar to Apache Bench, except that it can handle SSL, which ab cannot. If you don't care about SSL, ab should work fine.

It was a while back, but I ended up submitting a patching to Siege that takes care of the mis-matched cookie domain issue, so if you download 2.70b1 or later, you won't run into the issues I did.

I put together a wrapper script for Siege, similar to what I'd done with Apache Bench, which can be found on github.

Here's a quick tutorial on how to build/use the latest siege with my wrapper script to benchmark pages as an authenticated user in Drupal (tested on OSX, Lenny, and Jaunty):

Get/Build Siege

Download the Siege source from the website (must be 2.70b1 or above):

wget ftp://ftp.joedog.org/pub/siege/beta/siege-2.70b1.tar.gz

Untar it:

tar -xzf siege-2.70b1.tar.gz

Build it:

cd siege-2.70b1
./configure
make
sudo make install

Make a siege config

sudo siege.config

Get wrapper script

Clone the wrapper script from github. If you don't have git installed (?!?!?), you can download it from the github page.

git clone git://github.com/msonnabaum/DrupalSiege.git
cd DrupalSiege

Test things!

You call the script as if you were calling siege itself like so:

./drplsiege.sh -c1 -r10 www.yourdrupalsite.com/admin/build/modules

That will then prompt you for your username/password to login to Drupal before siege is run. Call siege --help to get a list of options you can use. For the most part, you'll be using -c and -r, which is the number of concurrent users and how many times the test is run. The above example will use 1 user to request the modules page 10 times.

If you're trying to test a page as an anonymous user, don't use the drplsiege wrapper, just call siege directly.

urls.txt

Thanks loads for this great tutorial. It's very useful.

I was just wondering if it's possible to use it in conjunction with the urls.txt file? I don't seem to be able to get it to work using the normal siege options.

I have tried ./drplsiege.sh -f /usr/local/etc/urls.txt , which just hangs (as it does if I just run ./drplsiege.sh with no options, whereas passing concurrency etc. works fine)

I have also tried ./drplsiege.sh --f=/usr/local/etc/urls.txt , which brings up an error: "Password: head: cannot open `=/usr/local/etc/urls.txt' for reading: No such file or directory"

Am I just barking up the wrong tree with this? Any advice much appreciated.

Will: I'm able to get the

Will: I'm able to get the following working (urls.txt is in the same directory)

sh drplsiege.sh -c5 -r10 -f urls.txt

Hi. Thanks for the

Hi. Thanks for the reply.

Odd, it still hangs for me, even when I put the URLs file in the same folder.

When you run it do you see the output straight away (like you do when running it for a specific URL)? I'm wondering whether it's actually running all the tests in the background and I'm just being impatient.

About to head off for the day so I'll leave it running and see if anything's happened in the morning.