LAYINGSIEGE(7)						 Miscellaneous Information Manual					    LAYINGSIEGE(7)

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 char-
       acterizes 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 ulti-
       mately 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  addi-
       tional requests.  In truth the Linux box is suffering from a lack of RAM, it has about 200MB, hardly enough to be handling one hundred con-
       current 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 (C) 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  MER-
       CHANTABILITY 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.

SEE ALSO

       siege(1) siege.config(1) urls_txt(5)

Siege v2.70							   April-17-2012						    LAYINGSIEGE(7)