1SIEGE(1) General Commands Manual SIEGE(1)
2
6 Siege was designed orignally as a internet usage simulator. In short,
7 its role was to simulate the activity of many simultaneous users hit‐
8 ting a HTTP server. We were debugging some java code and during that
9 process we arrived at a point where the code could withstand an accept‐
10 able number of users hitting a single URL but it could not withstand
11 the seemingly random activity that characterizes many users hitting
12 many URLs on a webserver.
13 In order to debug the problem in a lab environment, I developed a pro‐
15 gram that simply read a bunch of URLs ( we used images, scripts, static
16 html, jsps, etc. ) into memory and hit them randomly. The result was a
17 success. We were able to break the code in the lab, an occurance which
18 ultimately allowed us to fix it and put it into production. As the
19 developers code improved, siege improved until we ultimately had good
20 java code and a pretty decent regression tool. It was helpful for us,
21 I hope it is helpful to you.
22 In order to feel comfortable putting code into production, you need a
24 way to measure its performance and to determine its threshold for fail‐
25 ure. If you break your database pool at 250 simultaneous users and you
26 average less then one-hundred simultaneous users and the code performs
27 favorably, you can feel good about putting it into production. At the
28 same time, if you should monitor trends in your site's activity and
29 prepare for the moment when your traffic starts to near your threshold
30 for failure.
31 As a webdeveloper or websystems administrator you have little to no
33 control over your user group. They can visit your site anytime day or
34 night. Your domain name could resemble a popular site, yoohoo.com? And
35 when was the last time marketing informed you about an approaching
36 advertising blitz? You must be prepared for anything. That is why
37 stress and performance testing is so important. I would not recommend
38 putting anything into production until you have a good feel for how it
39 will perform under duress.
40
43 Whenever we add new code to a webserver, we place the server "under
44 siege." First we stressthe new URL(s) and then we pound the server with
45 regression testing with the new URLs added to the configuration file.
46 We want to see if the new code will stand on its own, plus we want to
47 see if it will break anything else.
48 The following statistics were gleaned when I laid siege to a single URL
50 on a http server:
51 Transactions: 1000 hits
53 Elapsed time: 617.99 secs
54 Data transferred: 4848000 bytes
55 Response time: 59.41 secs
56 Transaction rate: 1.62 trans/sec
57 Throughput: 7844.79 bytes/sec
58 Concurrency: 96.14
59 Status code 200: 1000
60 In the above example, we simulated 100 users hitting the same URL 10
62 times, a total of 1000 transactions. The elapsed time is measured from
63 the first transaction to the last, in this case it took 617.99 seconds
64 to hit the http server 1000 times. During that run, siege recieved a
65 total of 4848000 bytes including headers. The response time is mea‐
66 sured by the duration of each transaction divided by the number of
67 transactions. The transaction rate is number of transactions divided
68 by elapsed time. Throughput is the measure of bytes recieved divided
69 by elapsed time. And the concurrency is the time of each transaction
70 divided by the elapsed time. The final statistic is Status code 200.
71 This is the number of pages that were effectively delivered without
72 server errors.
73 To create this example, I ran siege on my Sun workstation and I pounded
75 a GNU/Linux Intel box, essentially a workstation. The performance
76 leaves a lot to be desired. One indication that the server is strug‐
77 gling is the high concurrency. The longer the transaction, the higher
78 the concurrency. This server is taking a while to complete the trans‐
79 action and it continues to open new sockets to handle all the addi‐
80 tional requests. In truth the Linux box is suffering from a lack of
81 RAM, it has about 200MB, hardly enough to be handling one hundred con‐
82 current users. :-)
83 Now that we've stressed the URL(s) singly, we can add them to our main
85 configuration file and stress them with the rest of the site. The
86 default URLs file is SIEGE_HOME/etc/urls.txt.
87 Siege can allow websystems administrators a chance to see how their
89 servers perform under duress. I recommend running server performance
90 monitoring tools while it is under siege to gage your hardware / soft‐
91 ware configurations. The results can be surprising...
92 Siege was originally based on Lincoln Stein's torture.pl and if you
94 cannot it on your architecture, it is recommended that you run that
95 excellent perl script instead. I intentionally modeled my statistics
96 output after his in order to maintain similar reference.
97
100 Copyright © 2000 2001 2004 Jeffrey Fulmer, et al. <jeff@joedog.org>
101 This program is free software; you can redistribute it and/or modify it
103 under the terms of the GNU General Public License as published by the
104 Free Software Fo undation; either version 2 of the License, or (at your
105 option) any later version.
106 This program is distributed in the hope that it will be useful, but
108 WITHOUT ANY WARRANTY; without even the implied warranty of MER‐
109 CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
110 Public License for more details.
111 You should have received a copy of the GNU General Public License along
113 with this program; if not, write to the Free Software Foundation, Inc.,
114 675 Mass Ave, Cambridge, MA 02139, USA.
115
117 The most recent released version of siege is available by anonymous FTP
118 from sid.joedog.org in the directory pub/siege.
119
121 siege(1) siege.config(1) urls_txt(5)
122Siege v2.66 April-10-2007 SIEGE(1)