Siege is a useful load testing tool to add to your performance testing tool kit. From the website:
Siege is an HTTP load testing and benchmarking utility. It was designed to let web developers measure their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP, HTTPS and FTP protocols. It lets its user hit a server with a configurable number of simulated clients. Those clients place the server “under siege.”
Loading testing is useful for testing the performance of your site, and the infrastructure that it runs on. There’s nothing worse than having a page on your site posted on a popular site and watching your site crumble under the load. Siege can simulate activity on your site, and you can then use your site from your browser as you normally would, while your siege is running and really get a feel for how your site responds under load.
This blog post will cover installing Siege on OS X and Linux, and running a basic load test with Siege.
This tutorial assumes that you are comfortable using the command line to issue basic commands and have a website installed on your local machine that you can test.
First, head over to https://www.joedog.org/siege-home/ and find the URL for an archive of the latest version of the Siege application. At the time of writing, that’s Siege version 3.1.0.
Now open up the Terminal app, we will save this archive in our Downloads directory.
On OS X
cd ~/Downloads curl -O http://download.joedog.org/siege/siege-3.1.0.tar.gz
cd ~/Downloads wget http://download.joedog.org/siege/siege-3.1.0.tar.gz
Extract the archive
tar -xvf siege-3.1.0.tar.gz
Change to the archive directory
Configure and build it!
./configure make make install
Read the Docs
If you need to, consult the full Install Instructions.
Verify Installed Version
Great, now we can test that we have siege installed properly, let's verify the version we've installed on our system.
siege -V SIEGE 3.1.0
Hooray, we have version 3.1.0 of siege installed on our system, let’s get down to some testing!
Load Testing With Siege
I’m going to use a Drupal site that I have installed locally to load test. To start a basic siege run the following command using your desired site URL (I’m using http://drupal7.local):
This will start siege with the default options, which is 15 concurrent users accessing your site's index page, until you stop the siege, by pressing control+c.
This will provide the siege statistics for your test:
Lifting the server siege... done. Transactions: 385 hits Availability: 100.00 % Elapsed time: 76.02 secs Data transferred: 0.84 MB Response time: 2.40 secs Transaction rate: 5.06 trans/sec Throughput: 0.01 MB/sec Concurrency: 12.18 Successful transactions: 385 Failed transactions: 0 Longest transaction: 5.73 Shortest transaction: 0.31
Interpreting The Results of a Load Test
Now, first of all, my results are not that impressive, as I’m running this on a low powered virtual machine on my local machine, if you’re load testing production sites, you should expect much faster response times.
Transactions is the number of server hits. In the example, 385 transactions.
Elapsed time is the duration of the entire siege test. This is measured from the time the user invokes siege until the last simulated user completes its transactions. Shown above, the test took 76.02 seconds to complete.
Data transferred is the sum of data transferred to every siege simulated user. It includes the header information as well as content. Because it includes header information, the number reported by siege will be larger then the number reported by the server. In internet mode, which hits random URLs in a configuration file, this number is expected to vary from run to run.
Response time is the average time it took to respond to each simulated user’s requests.
Transaction rate is the average number of transactions the server was able to handle per second, in a nutshell: transactions divided by elapsed time.
Throughput is the average number of bytes transferred every second from the server to all the simulated users.
Concurrency is average number of simultaneous connections, a number which rises as server performance decreases.
Successful transactions is the number of times the server returned a code less then 400. Accordingly, redirects are considered successful transactions.
Testing Multiple Pages
In order to test multiple URLs we can use a URL file to provide a list of URLs to test during our siege. Create a text file called urls.txt, and add the URLs you’d like to test against (one per line), I’m creating mine in my user’s home directory at ~/urls.txt
Siege understands the following URL format: [protocol://] [servername.domain.xxx] [:portnumber] [/directory/file]
# Comments proceeded by a hash http://drupal7.local/ http://drupal7.local/node/2 http://drupal7.local/node/7 http://drupal7.local/rest/node
Now you can start siege and provide the path to the file you created, to start a test against those URLs:
siege -f /path/to/your/urls.txt
Internet mode is another interesting option in Siege, in which each the URLs that a user hits in the test is randomized. This mimics a real-life situation in which you can't predict which URL a person will visit on your site. The other implication of this option is that there is no guarantee that each page in the URLs text file will be hit, due to the randomization.
To start a Siege in internet mode, use the following command, again passing in the path of your urls.txt:
siege -if /path/to/your/urls.txt
Increasing the Number of Concurrent Users
Increasing the number of concurrent users is done with the -c flag, passing the number of concurrent user’s you would like to test with:
siege -if /path/to/your/urls.txt -c 500
‘ -c NUM ‘ ‘ –concurrent=NUM ‘
Concurrent users (requires argument): This option allows the user to stress the web server with NUM number of simulated users. The amount is limited only by the computing resources available, but realistically a couple of hundred simulated users is equal to many times that that number in actual user sessions. The number you select represents the number of transactions your server is handling. It does NOT represent the number of concurrent sessions. Remember, real users take some time to actually read the page that they’ve requested.
It’s also useful to use the -d flag which allows you to stagger the transactions:
siege -if /path/to/your/urls.txt -c 500 -d 3
‘ -d NUM ‘ ‘ –delay=NUM ‘ Each siege simulated user is delayed for a random number of seconds between one and NUM. If you are benchmarking performance, it is recommended that you use a 1 second delay ( -d1 ). The default value is three (3 ). This delay allows for the transactions to stagger rather then to allow them to pound the server in waves.
Siege has a lot more to offer, and I’d urge you to read the documentation in full to get a more complete understanding, but hopefully this tutorial will get you on your way.
If you need to Siege pages that require authentication as a Drupal User, check out this helper script: https://github.com/msonnabaum/DrupalSiege
Uninstalling Siege and Cleaning Up
If you decide you don’t want to have Siege installed on your system any longer, first uninstall it, then remove the source directory, and archives:
Change in to the directory you downloaded Siege to:
cd ~/Downloads/siege-3.1.0/ make uninstall
Now you can safely remove the source folder, and the archive at:
Much Ado about Performance
If your site feels like it is performing poorly while under siege, you will want to find out why! Some things to check:
- Server load
- Have you implementing any caching?
To learn more about performance and scalability, check out these video series and articles from Drupalize.Me and Lullabot.