Getting ready to roll out a site, but not sure how it will perform in real-world use? Take a look at Siege, a load-testing and benchmarking utility that will help stress test your setup before exposing it to the world.
Ready to roll out a site, but not sure how it will perform in real-world use? Consider Siege, an open source load-testing and benchmarking utility that will help stress test your setup before exposing it to the world.
Siege is a fantastic utility for helping with Linux server management by exposing problems before they go into production. It’s open source software (GPLv2 or later) and easy to get started with.
Siege is packaged for Debian and Ubuntu, but it doesn’t look to be packaged for Fedora and openSUSE (at least in the default repos). Do remember, though, it’s “i” before “e” — I nearly missed the package for Ubuntu by searching for “seige,” which (obviously) doesn’t exist.
The source, of course, is available. Note that the link to the latest version from the homepage returns an “unable to connect” error (at least as of this writing). However, the pub directory is available over HTTP even if the FTP server seems to be down.
Once installed, Siege is very easy to use. You can use Siege to test over HTTP and HTTPS — it has no support for FTP or other protocols at the moment.
To start with, you probably want to generate a Siege configuration file. You can generate a template quickly using
siege.config, which will drop a file called
.siege.rc in your home directory. Here, you can set many of the options for Siege, like the output format (including a CSV output rather than the older Siege format), how many concurrent users to simulate, duration, and so on. If you have fairly standard testing parameters, you can store them in the config rather than using them on the command line or specifying them in a script. If you want to use an alternative configuration file, use
export SIEGERC=/filename or
siege -R siegerc.
One thing Siege is good for is grabbing the HTTP headers quickly. If you just want to see HTTP headers, run
siege -g URL. Note that the URL must be the server name only if you just want to see what a server is running, or a full URL if you want to hit specific resources.
Now, let’s look at a sample test using
siege. Say you want to simulate 50 users hitting the resource simultaneously, with a delay of up to 10 seconds between requests:
siege -d10 -c50 http://mysite.com/blog/blah.php
-d option specifies the delay, while the
-c option tells
siege how many users it should simulate. Note that the
-d option is a random interval between 0 and X seconds, with X being the number of seconds you specify — so if you say 10 seconds, it may be 0 seconds, it may be 4 seconds, and so on — it just won’t be longer than 10.
If you want to give a site a real workout, you probably want to specify more than one URL. You can do this with a list of URLs in
~/etc/urls.txt or specify a text file with URLs using the
-f file option. If you want a simulation closer to real-world usage, you’ll want to use the
-ioption, which hits the URLs in the file randomly.
A fairly good template for testing might be:
siege -d10 -c50 -i -f mysite.txt
Be careful using Siege against production sites — especially dinky little VPSes with very little RAM. Not that I’d know from personal experience or anything. It should also go without saying that you should not use Siege against sites you’re not responsible. At best, doing so is impolite, but it could also be a violation of your ISP’s terms of service, and at worst it may be illegal.
While not a perfect simulation, Siege can help a great deal with performance testing. Although it looks like Siege development is a little slower these days, there are signs of life. If you’re looking for a solid, easy to use, load-testing tool, be sure try out Siege.
Joe ‘Zonker’ Brockmeier is a freelance writer and editor with more than 10 years covering IT. Formerly the openSUSE Community Manager for Novell, Brockmeier has written for Linux Magazine, Sys Admin, Linux Pro Magazine, IBM developerWorks, Linux.com, CIO.com, Linux Weekly News, ZDNet, and many other publications. You can reach Zonker at firstname.lastname@example.org and follow him on Twitter.