Sublime Coding

Using Siege to Stress Test an Application

Jared Smith -

Recently the company I work for migrated to new servers. During this migration we were all fairly confident that our new architecture would work and would be able to sustain considerable traffic. How much traffic is "considerable traffic"? In all honesty, none of our team and even our consultants, could say for sure.

In order to gain confidence in the new architecture we needed to test with our applications while it was running and getting real world data with out actually impacting our users. There are many options for stress testing applications, Jmeter, Apache Bench, Siege, Tsung, Locust. We chose to use Siege, it was one of the easiest to configure and use, and it just worked.

Let's install Siege and run some test against your application.

Hombrew
brew install siege
Linux

Open Terminal

Download the latest version of siege ( 4.0.4 – current)

http://download.joedog.org/siege/siege-latest.tar.gz

Extract the tarball

$ tar -xvf siege-latest.tar.gz

Change directories to the extracted directory (again, currently siege-4.0.4)

$ cd siege-4.0.4/

Run the following commands (one at a time) to build and install siege. If you have an older version of Siege read the INSTALL file for more instructions.

$ ./configure
$ make
$ make install
Check your version

Once your installation is complete, check your version to make sure it installed correctly:

$ siege --version

You should see an output like this, your version may be different:

SIEGE 4.0.4
Installing Siege Ubuntu
$ sudo apt-get install siege
Installing Siege CentOS
$ sudo yum install siege
Using Siege

Siege out of the Box will work for most stress testing needs. There are a ton of configuration options. To generate the default config file run the following command.

$ siege.config

It will show you where it added the file. Typically this gets added into your users home directory.

To start running tests against your website URL simply run:

$ siege -c10 -d10 -v http://www.mywebsite.com/
  • Warning: Do not try this against your production applications, Siege can very easily kick over servers, and require you to restart server services.

-c is the number of concurrent users this can be ramped up into the hundreads.
-d is the delay between each users request, this is a random interval between 1 and the number specified in this case its 1-10 seconds.
-v tells the output from siege to be verbose and produce details information about each transaction.

More commonly you do not want to slam a single sever URL with one request because this does not simulate real world traffic. Users do not just hit your home page repeatedly with no delay between.

To get a better similation of user traffic we supplied Siege with a list of URLs to hit randomly. The URLs we used were pulled from apache logs, but you could pull them from any location you like. Web server logs tend to work the best since its the closest to real traffic.

Below is a common test command we ran while testing our new servers. We adjusted the variables of -c and -d to increase the number of users, and how the traffic was quickly interacting with the endpoints. Two new parameters get introduced here.

$ siege -c 50 -d 10 -i -f /PathToFile/siegeTest.txt

-f is the path to the file you want to use. Urls should be serperated by a line break.
-i tells siege to randomly select URLs from this file. Each user it generates will randomly select one line and execute that request.

Here is an example Siege url file, so you can see how the URLs are organized.

http://www.mywebsite.com/
http://www.mywebsite.com/home
http://www.mywebsite.com/about
http://www.mywebsite.com/contact
http://www.mywebsite.com/posts
http://www.mywebsite.com/post/some-article
http://www.mywebsite.com/post/another-article
http://www.mywebsite.com/subscribe
http://www.mywebsite.com/rss
http://www.mywebsite.com/example-page

Happy sieging your servers!