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 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 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.
SEE ALSO
siege(1) siege.config(1) urls_txt(5)