Recently the company I work for migrated to new servers. Specifically a migration from physical boxes to VMs. During this migration we were all fairly confident that our architecture would work and would be able to sustain considerable traffic. What is considerable traffic? In all honesty none of us even our consultants could say for sure. In order to test the system we needed to test with our applications running and getting real world data with out actually impacting our users. In researching this I found there were two tools that seem to keep showing up. The first was Jmeter, the second was Siege. If you have access to a linux box I highly recommend siege over Jmeter for simple stress testing.
Siege turned out to be easy to use, configure, and run. So here is a little information on how to get started with siege and run some test against you application.
Installing Siege Mac OSX
Download the latest version of siege ( 3.0.6 – current)
Extract the tarball
$ tar -xvf siege-latest.tar.gz
Change directories to the extracted directory (again, currently siege-3.0.6)
$ cd siege-3.0.6/
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
This will install siege to /usr/local/bin/. This should already be in your PATH, so type:
$ siege --version
You should see an output like this:
Installing Siege Ubuntu
$ sudo apt-get install siege
Installing Siege CentOS
$ sudo yum install siege
Using Siege to test.
Siege out of the Box will work for most of your stress testing needs. There are a ton of configuration options. To generate the config file run, it will show you where it added the file. Typically this gets added into your users home directory.
- Warning: Do not try this against your production applications, Siege can very easily kick over servers, and require you to restart server services.
To start running tests against your website URL simply run
$ siege -c10 -d10 -v http://www.mywebsite.com/
-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 they does not simulate real world traffic. Users do not just hit your home page repeatedly.
$ siege -c 50 -d 10 -i -f /PathToFile/siegeTest.txt
this was a common test command we ran while testing our configuration. We would adjust the variables of -c and -d to increase the strain, or change how the traffic was interacting. Two new parameters get introduced here.
-f tells siege to read a series of URLs from a given file.
-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 a siege_test_example, so you can see how the URLs are organized in a siege file
Happy sieging your servers!
Subscribe to Sublimecoding
Get the latest posts delivered right to your inbox