Load Testing your Site with Siege

Image

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.

Assumptions

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.

Installing Siege

Download

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.

Save

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

On Linux

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

cd siege-3.1.0

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):

siege 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.

Terminology

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

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:

~/Downloads/siege-3.1.0
~/Downloads/siege.-3.1.0.tar.gz

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?

Resources

To learn more about performance and scalability, check out these video series and articles from Drupalize.Me and Lullabot.

Video: Drupal Performance & Scalability Series

Video: An Overview of Performance & Scalability

Articles tagged with Performance and Scalability on Lullabot.com