Man Linux: Main Page and Category List


       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,  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.


       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 SIEGE_HOME/etc/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 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 © 2000 2001 2004 Jeffrey Fulmer, et al. <>

       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
       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.


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


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