Developers are always worried about how their web application will perform to the real world users. Once the site is rolled out; it may come down due to sudden surge in its use, depicting DoS (Denial of Service) attack. Wouldn’t it be nice to test and benchmark your web application in development and before moving to pre-production or production servers. ‘Siege‘ can be the answer for this.
Siege is a command line utility which exposes the performance related issues of web based applications. Siege simulates the given number of users who are calling the url; within a given period of time. For example; Siege can tell – “How will be the performance of the server; if it is called by 100 users within a period of 10 second”.
Siege is a command line utility which exposes the performance related issues of web based applications. Siege simulates the given number of users who are calling the url; within a given period of time. For example; Siege can tell – “How will be the performance of the server; if it is called by 100 users within a period of 10 second”.
Following are the features of Siege.
Siege is an open source load testing and benchmarking utility.
Siege can be used for HTTP/HTTPS and basic authentication based sites.
Siege creates real-world simulation of how the application will perform for given number of users over a given period of time.
Siege supports GET, POST HTTP methods, Cookies and transaction logging.
Siege can be used for extracting and checking the HTTP headers.
Multiple urls can be tested simultaneously with Siege.
Installing Siege
Siege can be installed on Linux (or other *nix), Solaris, Mac systems. Currently there is no installer for Windows (as its written on GNU/Linux) but Windows based server urls can be tested.
Installing on Linux
You can download latest package distribution from its developer site.
You can download latest package distribution from its developer site.
1
2
3
4
5
6
7
8
9
| //Untar the downloaded package using command line$ tar xvzf siege-latest.tar.gz //Configure it$ ./configure //Now, compile and install$ make$ make install |
Running Siege
The url can be tested using following command.
1
| siege -c5 -d10 -r1 -v http://www.yoursite.com |
Siege utility can have following options.
-cNUM : is to simulate the number of concurrent users (NUM count can be changed).
-dNUM : is the duration in second to run the test. (NUM is in seconds)
-rNUM : is the number of times the test can be repeated.
-v : is the verbose mode. Transaction information is printed on the screen.
-i : is the for internet. The requests are fired randomly between the number given in -d option.
-f : is used if multiple urls are tested from file
Siege can be used to check the header of the site or webpage using following command.
1
| siege -g http://www.yoursite.com |
Multiple urls can be tested by creating a file with the multiple urls separated by a line. The command is
1
| siege -d10 -c50 -i -f /path_to_file/testfile.txt |
Result
The result is printed as shown below. The url in the command is masked. You can replace it with the url to be tested.
The various parameters in the output can be analysed to check the performance of the server against the values provided. At start, keep the values of -c and -d options low and then increment them linearly, observing the ‘Failed Transactions’ count. The maximum values used till the ‘Failed Transactions’ changes to non-zero can be treated as the threshold values for the application and the server.
Do not keep the values for -c,-d or -r options high in the beginning; this may flood the server with too many requests; resulting in its failure.
The various parameters in the output can be analysed to check the performance of the server against the values provided. At start, keep the values of -c and -d options low and then increment them linearly, observing the ‘Failed Transactions’ count. The maximum values used till the ‘Failed Transactions’ changes to non-zero can be treated as the threshold values for the application and the server.
Do not keep the values for -c,-d or -r options high in the beginning; this may flood the server with too many requests; resulting in its failure.