Siege! Benchmarking your web applications

Nov 23, 2011 • 2 min read • performance

Performance is absolutely everything… well, perhaps not everything, but it’s bloody important! It’s useless trying to improve the performance of your web app if you’ve no way of measuring your success.

With this in mind you might want to add Siege to your tool belt. Siege is a regression and benchmarking tool that allows you to throw a load of concurrent requests at your app within a specific time frame. Keep reading for an introduction to Siege.

I’m going to be running Siege on my Debian 6 server, this process should be the same for Ubuntu, although you might have to do a bit more work to get going on other linux flavours.

Note: Here’s a great article on how to compile Siege on Mac.

So, lets install Siege:

sudo apt-get install siege

That was easy, apt-get will resolve dependencies for you so if everything’s gone well you should be able to get stuck right in, lets say we’ve got a WordPress instance under localhost that we want to test, simply run this command:

siege -c 5 -b -t30s 'http://localhost'

Here’s a quick explanation of the options we’ve used above:

-c 5 – run with five concurrent requests
-b – benchmark mode
-t30s – time, run for 30 seconds
http://localhost – the target of the benchmark

When Siege has completed benchmarking your app we get this back:

Lifting the server siege...      done.
Transactions:                     21 hits
Availability:                 100.00 %
Elapsed time:                  29.35 secs
Data transferred:               0.55 MB
Response time:                  5.75 secs
Transaction rate:               0.72 trans/sec
Throughput:                     0.02 MB/sec
Concurrency:                    4.12
Successful transactions:          21
Failed transactions:               0
Longest transaction:            8.16
Shortest transaction:           4.73

We could analyse each of the bits of data above, and which piece of data you analyse and compare is really specific to what you’re trying to find out from your benchmarking. For the work I do I’m really interested in reducing the response time, of which will impact on how many transactions will complete in our 30 seconds of benchmarking.

Of course like any experiment you’ll need a set of figures to act as your control, run Siege before making changes to your app and then again after each revision, being able to compare before and after will give you a handle on whether your changes are improving performance.

There are plenty of options for using Siege, an explanation of which can be found on the Siege manual page.