Ubuntu Manpage: Siege - An HTTP/HTTPS stress tester was designed orignally as a internet usage simulator. In short, its

NAME

Siege - An HTTP/HTTPS stress tester was designed orignally as a internet usage simulator. In short, its
role was to simulate the activity of many simultaneous users hitting a HTTP server. We were debugging
some java code and during that process we arrived at a point where the code could withstand an acceptable
number of users hitting a single URL but it could not withstand the seemingly random activity that
characterizes many users hitting many URLs on a webserver.

In order to debug the problem in a lab environment, I developed a program that simply read a bunch of
URLs ( we used images, scripts, static html, jsps, etc. ) into memory and hit them randomly. The result
was a success. We were able to break the code in the lab, an occurance which ultimately allowed us to
fix it and put it into production. As the developers code improved, siege improved until we ultimately
had good java code and a pretty decent regression tool. It was helpful for us, I hope it is helpful to
you.

In order to feel comfortable putting code into production, you need a way to measure its performance and
to determine its threshold for failure. If you break your database pool at 250 simultaneous users and
you average less then one-hundred simultaneous users and the code performs favorably, you can feel good
about putting it into production. At the same time, if you should monitor trends in your site's activity
and prepare for the moment when your traffic starts to near your threshold for failure.

As a webdeveloper or websystems administrator you have little to no control over your user group. They
can visit your site anytime day or night. Your domain name could resemble a popular site, yoohoo.com?
And when was the last time marketing informed you about an approaching advertising blitz? You must be
prepared for anything. That is why stress and performance testing is so important. I would not recommend
putting anything into production until you have a good feel for how it will perform under duress.

LAYING SIEGE

Whenever we add new code to a webserver, we place the server "under siege." First we stressthe new URL(s)
and then we pound the server with regression testing with the new URLs added to the configuration file.
We want to see if the new code will stand on its own, plus we want to see if it will break anything else.

The following statistics were gleaned when I laid siege to a single URL on a http server:

Transactions: 1000 hits
Elapsed time: 617.99 secs
Data transferred: 4848000 bytes
Response time: 59.41 secs
Transaction rate: 1.62 trans/sec
Throughput: 7844.79 bytes/sec
Concurrency: 96.14
Status code 200: 1000

In the above example, we simulated 100 users hitting the same URL 10 times, a total of 1000 transactions.
The elapsed time is measured from the first transaction to the last, in this case it took 617.99 seconds
to hit the http server 1000 times. During that run, siege received a total of 4848000 bytes including
headers. The response time is measured by the duration of each transaction divided by the number of
transactions. The transaction rate is number of transactions divided by elapsed time. Throughput is the
measure of bytes received divided by elapsed time. And the concurrency is the time of each transaction
divided by the elapsed time. The final statistic is Status code 200. This is the number of pages that
were effectively delivered without server errors.

To create this example, I ran siege on my Sun workstation and I pounded a GNU/Linux Intel box,
essentially a workstation. The performance leaves a lot to be desired. One indication that the server
is struggling is the high concurrency. The longer the transaction, the higher the concurrency. This
server is taking a while to complete the transaction and it continues to open new sockets to handle all
the additional requests. In truth the Linux box is suffering from a lack of RAM, it has about 200MB,
hardly enough to be handling one hundred concurrent users. :-)

Now that we've stressed the URL(s) singly, we can add them to our main configuration file and stress them
with the rest of the site. The default URLs file is /etc/siege/urls.txt.

Siege can allow websystems administrators a chance to see how their servers perform under duress. I
recommend running server performance monitoring tools while it is under siege to gage your hardware /
software configurations. The results can be surprising...

Siege was originally based on Lincoln Stein's torture.pl and if you cannot it on your architecture, it is
recommended that you run that excellent perl script instead. I intentionally modeled my statistics
output after his in order to maintain similar reference.

COPYRIGHT

       Copyright © 2000 2001 2004 Jeffrey Fulmer, et al. <jeff@joedog.org>

       This  program  is  free  software;  you  can  redistribute it and/or modify it under the terms of the GNU
       General Public License as published by the Free Software Fo undation; either version 2 of the License, or
       (at your option) any later version.

       This program is distributed in the hope that it will be useful, but WITHOUT ANY  WARRANTY;  without  even
       the  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
       License for more details.

       You should have received a copy of the GNU General Public License along with this program; if not,  write
       to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

AVAILABILITY

       The  most  recent  released  version  of  siege  is available by anonymous FTP from sid.joedog.org in the
       directory pub/siege.

NAME

LAYING SIEGE

COPYRIGHT

AVAILABILITY

SEE ALSO