Network stress testing is taken for granted sometimes however it is extremely useful in many aspects of a network. Typically when someone is thinking of stress testing something technology related they are thinking of stress testing a web application of some sort however it is beneficial to also stress test every piece of network hardware from the firewall to the web server that the application is running on to make sure there are no weaknesses once packets touch your network. With that said there are some great applications within Backtrack that provide stress testing capabilities such as siege which is classified as a HTTP/HTTPS Stress Tester which depending on the location you test from could also test network hardware between the Internet and the web server running the application being tested.

Initial siege Configuration & siege File Locations:

When you first attempt to launch siege you should receive the below warning message letting you know that a default siege configuration file does not exist.

siege: could not open /etc/siegerc
run 'siege.config' to generate a new .siegerc file

To remove the warning run siege.config from the Backtrack CLI and a siege configuration file will be generated. The file won’t actually be /etc/siegerc but instead will be /root/.siege.rc or /<user>/.siege.rc depending on which user you are logged in as. Below you can click on the Default .siege.rc Siege Configuration File to see the contents of .siege.rc file. To tune Siege for what you need it for it would be worth while to read through a defauly .siege.rc file and see what Siege settings can be adjusted.

Siege Default Configuration File Example: .siege.rc
Default .siege.rc Configuration File

# Updated by Siege 2.72, February-17-2012
# Copyright 2000-2007 by Jeffrey Fulmer, et al.
# Siege configuration file — edit as necessary
# For more information about configuring and running
# this program, visit:

# Variable declarations. You can set variables here
# for use in the directives below. Example:
# Reference variables inside ${} or $(), example:
# proxy-host = ${PROXY}
# You can also reference ENVIRONMENT variables without
# actually declaring them, example:
# logfile = $(HOME)/var/siege.log

# Signify verbose mode, true turns on verbose output
# ex: verbose = true|false
verbose = false

# CSV Verbose format: with this option, you can choose
# to format verbose output in traditional siege format
# or comma separated format. The latter will allow you
# to redirect output to a file for import into a spread
# sheet, i.e., siege > file.csv
# ex: csv = true|false (default false)
# csv = true

# Timestamp format: with this option, you can choose to
# print a timestamp each line of output
# example: timestamp = true|false (default false)
# sample: [Sat, 2010-11-20 10:39:13] HTTP/1.1 200 0.12 secs: 4003 bytes ==> /
# timestamp = true

# Full URL verbose format: By default siege displays
# the URL path and not the full URL. With this option,
# you # can instruct siege to show the complete URL.
# ex: fullurl = true|false (default false)
# fullurl = true

# Display id: in verbose mode, display the siege user
# id associated with the HTTP transaction information
# ex: display-id = true|false
# display-id =

# Show logfile location. By default, siege displays the
# logfile location at the end of every run when logging
# You can turn this message off with this directive.
# ex: show-logfile = false
show-logfile = true

# Default logging status, true turns logging on.
# ex: logging = true|false
logging = true

# Logfile, the default siege logfile is $PREFIX/var/siege.log
# This directive allows you to choose an alternative log file.
# Environment variables may be used as shown in the examples:
# ex: logfile = /home/jeff/var/log/siege.log
# logfile = ${HOME}/var/log/siege.log
# logfile = ${LOGFILE}
# logfile =

# HTTP protocol. Options HTTP/1.1 and HTTP/1.0.
# Some webservers have broken implementation of the
# 1.1 protocol which skews throughput evaluations.
# If you notice some siege clients hanging for
# extended periods of time, change this to HTTP/1.0
# ex: protocol = HTTP/1.1
# protocol = HTTP/1.0
protocol = HTTP/1.1

# Chunked encoding is required by HTTP/1.1 protocol
# but siege allows you to turn it off as desired.
# ex: chunked = true
chunked = true

# Cache revalidation.
# Siege supports cache revalidation for both ETag and
# Last-modified headers. If a copy is still fresh, the
# server responds with 304.
# HTTP/1.1 200 0.00 secs: 2326 bytes ==> /apache_pb.gif
# HTTP/1.1 304 0.00 secs: 0 bytes ==> /apache_pb.gif
# HTTP/1.1 304 0.00 secs: 0 bytes ==> /apache_pb.gif
# ex: cache = true
cache = false

# Connection directive. Options “close” and “keep-alive”
# Starting with release 2.57b3, siege implements persistent
# connections in accordance to RFC 2068 using both chunked
# encoding and content-length directives to determine the
# page size. To run siege with persistent connections set
# the connection directive to keep-alive. (Default close)
# CAUTION: use the keep-alive directive with care.
# DOUBLE CAUTION: this directive does not work well on HPUX
# TRIPLE CAUTION: don’t use keep-alives until further notice
# ex: connection = close
# connection = keep-alive
connection = close

# Default number of simulated concurrent users
# ex: concurrent = 25
concurrent = 15

# Default duration of the siege. The right hand argument has
# a modifier which specifies the time units, H=hours, M=minutes,
# and S=seconds. If a modifier is not specified, then minutes
# are assumed.
# ex: time = 50M
# time =

# Repetitions. The length of siege may be specified in client
# reps rather then a time duration. Instead of specifying a time
# span, you can tell each siege instance to hit the server X number
# of times. So if you chose ‘reps = 20′ and you’ve selected 10
# concurrent users, then siege will hit the server 200 times.
# ex: reps = 20
# reps =

# Default URLs file, set at configuration time, the default
# file is PREFIX/etc/urls.txt. So if you configured siege
# with –prefix=/usr/local then the urls.txt file is installed
# int /usr/local/etc/urls.txt. Use the “file = ” directive to
# configure an alternative URLs file. You may use environment
# variables as shown in the examples below:
# ex: file = /export/home/jdfulmer/MYURLS.txt
# file = $HOME/etc/urls.txt
# file = $URLSFILE
# file =

# Default URL, this is a single URL that you want to test. This
# is usually set at the command line with the -u option. When
# used, this option overrides the urls.txt (-f FILE/–file=FILE)
# option. You will HAVE to comment this out for in order to use
# the urls.txt file option.
# ex: url =
# url =

# Default delay value, see the siege(1) man page.
# This value is used for load testing, it is not used
# for benchmarking.
# ex: delay = 3
delay = 1

# Connection timeout value. Set the value in seconds for
# socket connection timeouts. The default value is 30 seconds.
# ex: timeout = 30
# timeout =

# Session expiration: This directive allows you to delete all
# cookies after you pass through the URLs. This means siege will
# grab a new session with each run through its URLs. The default
# value is false.
# ex: expire-session = true
# expire-session =

# Failures: This is the number of total connection failures allowed
# before siege aborts. Connection failures (timeouts, socket failures,
# etc.) are combined with 400 and 500 level errors in the final stats,
# but those errors do not count against the abort total. If you set
# this total to 10, then siege will abort after ten socket timeouts,
# but it will NOT abort after ten 404s. This is designed to prevent
# a run-away mess on an unattended siege. The default value is 1024
# ex: failures = 50
# failures =

# Internet simulation. If true, siege clients will hit
# the URLs in the urls.txt file randomly, thereby simulating
# internet usage. If false, siege will run through the
# urls.txt file in order from first to last and back again.
# ex: internet = true
internet = false

# Default benchmarking value, If true, there is NO delay
# between server requests, siege runs as fast as the web
# server and the network will let it. Set this to false
# for load testing.
# ex: benchmark = true
benchmark = false

# Set the siege User-Agent to identify yourself at the
# host, the default is: JoeDog/1.00 [en] (X11; I; Siege #.##)
# But that wreaks of corporate techno speak. Feel free
# to make it more interesting :-) Since Limey is recovering
# from minor surgery as I write this, I’ll dedicate the
# example to him…
# ex: user-agent = Limey The Bulldog
# user-agent =

# Accept-encoding. This option allows you to specify
# acceptable encodings returned by the server. Use this
# directive to turn on compression. By default we accept
# gzip compression.
# ex: accept-encoding = *
# accept-encoding = gzip
# accept-encoding = compress;q=0.5;gzip;q=1
accept-encoding = gzip

# Siege spawns a thread and runs a spinner to entertain you
# as it collects and computes its stats. If you don’t like
# this feature, you may turn it off here.
# ex: spinner = false
spinner = true

# WWW-Authenticate login. When siege hits a webpage
# that requires basic authentication, it will search its
# logins for authentication which matches the specific realm
# requested by the server. If it finds a match, it will send
# that login information. If it fails to match the realm, it
# will send the default login information. (Default is “all”).
# You may configure siege with several logins as long as no
# two realms match. The format for logins is:
# username:password[:realm] where “realm” is optional.
# If you do not supply a realm, then it will default to “all”
# ex: login = jdfulmer:topsecret:Admin
# login = jeff:supersecret
# login =

# WWW-Authenticate username and password. When siege
# hits a webpage that requires authentication, it will
# send this user name and password to the server. Note
# this is NOT form based authentication. You will have
# to construct URLs for that.
# ex: username = jdfulmer
# password = whoohoo
# username =
# password =

# ssl-cert
# This optional feature allows you to specify a path to a client
# certificate. It is not neccessary to specify a certificate in
# order to use https. If you don’t know why you would want one,
# then you probably don’t need this feature. Use openssl to
# generate a certificate and key with the following command:
# $ openssl req -nodes -new -days 365 -newkey rsa:1024 \
# -keyout key.pem -out cert.pem
# Specify a path to cert.pem as follows:
# ex: ssl-cert = /home/jeff/.certs/cert.pem
# ssl-cert =
# ssl-key
# Use this option to specify the key you generated with the command
# above. ex: ssl-key = /home/jeff/.certs/key.pem
# You may actually skip this option and combine both your cert and
# your key in a single file:
# $ cat key.pem > client.pem
# $ cat cert.pem >> client.pem
# Now set the path for ssl-cert:
# ex: ssl-cert = /home/jeff/.certs/client.pem
# (in this scenario, you comment out ssl-key)
# ssl-key =

# ssl-timeout
# This option sets a connection timeout for the ssl library
# ex: ssl-timeout = 30
# ssl-timeout =

# ssl-ciphers
# You can use this feature to select a specific ssl cipher
# for HTTPs. To view the ones available with your library run
# the following command: openssl ciphers
# ex: ssl-ciphers = EXP-RC4-MD5
# ssl-ciphers =

# Login URL. This is the first URL to be hit by every siege
# client. This feature was designed to allow you to login to
# a server and establish a session. It will only be hit once
# so if you need to hit this URL more then once, make sure it
# also appears in your urls.txt file.
# ex: login-url = POST name=jeff&pass=foo
# Siege versions after 2.69 support multi logins; you can configure
# them with multiple login-url directives. Place each one on a separate
# line. Siege loops through each login then starts again at the beginning
# after it uses the last one. If you have more users than login-urls, then
# siege starts reassigning ones that have already been used.
# ex: login-url =
# login-url =
# login-url =
# login-url =

# Proxy protocol. This option allows you to select a proxy
# server stress testing. The proxy will request the URL(s)
# specified by -u”” OR from the urls.txt file.
# ex: proxy-host =
# proxy-port = 8080
# proxy-host =
# proxy-port =

# Proxy-Authenticate. When scout hits a proxy server which
# requires username and password authentication, it will this
# username and password to the server. The format is username,
# password and optional realm each separated by a colon. You
# may enter more than one proxy-login as long as each one has
# a different realm. If you do not enter a realm, then scout
# will send that login information to all proxy challenges. If
# you have more than one proxy-login, then scout will attempt
# to match the login to the realm.
# ex: proxy-login: jeff:secret:corporate
# proxy-login: jeff:whoohoo
# proxy-login =

# Redirection support. This option allows to to control
# whether a Location: hint will be followed. Most users
# will want to follow redirection information, but sometimes
# it’s desired to just get the Location information.
# ex: follow-location = false
# follow-location =

# Zero-length data. siege can be configured to disregard
# results in which zero bytes are read after the headers.
# Alternatively, such results can be counted in the final
# tally of outcomes.
# ex: zero-data-ok = false
# zero-data-ok =

# end of siegerc

What Is siege HTTP/HTTPS Stress Tester Used For:

The siege application is actually useful for more than just stress testing secure and non-secure HTTP. Siege actually provides a really clean output of the headers from a specific URL which will be displayed a bit below in the article. What siege is really built for though is stress testing HTTP and HTTPS web applications by simulating traffic to the web application. There are a ton of settings that can be set for siege but below when we go into more detail about actually using siege we will discuss those options.

Use siege To Pull Down Headers And Display The Transaction:

root@bt:~# siege -g
GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.72)
Connection: close

HTTP/1.1 200 OK
Date: Wed, 25 Apr 2012 05:45:16 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Tue, 10 May 2011 07:45:00 GMT
ETag: "a711f-b1-4a2e722183700"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 146
Connection: close
Content-Type: text/html


Above we are using siege to simply output HTTP headers from a remote server. This type of information can be very useful however it can be obtained by numerous tools including netcat or nc, nmap, and many others so it is unlikely you will use siege in this format during a pentest unless you were already using siege for something else at the time you needed the HTTP headers.

Siege HTTP/HTTPS Stress Testing:

So the main reason to use siege is for HTTP and/or HTTPS load testing. I put together a quick example using the default configuration file generated above to show a simple HTTP stress test example. Again the purpose of siege is to stress test a new web application or updates to code such as ruby that are served over a HTTP or HTTPS web server such as Apache. First we need to create a text file with a single URL or multiple URL’s in it. Create a file named urls.txt located in sub directory called siege within the user who will run siege’s home directory such as /root/siege/urls.txt. For this siege example I created a quick list of URL’s located in the Backtrack Linux servers Apache root directory. I created each of the files and then started the Apache web server on the Backtrack server only for this siege test.

Example Siege /root/siege/urls.txt File:

The contents of each of the above files located on the Backtrack Linux server were simple such as “test” in the HTML files and “” in the PHP files. Once you have the list of URL’s created in urls.txt you can launch the siege command similar to the below example.

Example Siege Command Execution Initial Output:

root@bt:~/root# siege
** SIEGE 2.72
** Preparing 15 concurrent users for battle.
The server is now under siege...
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.25 secs:    8952 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.24 secs:    8952 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.25 secs:    8953 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 404   0.00 secs:     242 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.26 secs:    8951 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.25 secs:    8953 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 404   0.00 secs:     242 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.25 secs:    8952 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.02 secs:    8954 bytes ==>
[Sun, 2012-04-29 01:24:54] HTTP/1.1 200   0.01 secs:    8953 bytes ==>

The “siege” or HTTP/HTTPS stress test will run for a set amount of time which is specified in .siegerc. In the above example I set “verbose = true” so you could see what exactly is happening during the siege. Now in the below example I set the time to run to 1 minute by setting “time = 1M” and turning verbosity off by setting “verbose = false”. I also let the command run for the entire sixty seconds so you could see the output of siege and where it would be useful for testing new code before it is released or for testing web applications to see what could be handled.

Example Siege Command Execution Running For One Minute:

root@bt:~# siege
** SIEGE 2.72
** Preparing 15 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:                   1719 hits
Availability:                 100.00 %
Elapsed time:                  59.22 secs
Data transferred:               7.08 MB
Response time:                  0.00 secs
Transaction rate:              29.03 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                    0.04
Successful transactions:        1556
Failed transactions:               0
Longest transaction:            0.03
Shortest transaction:           0.00

FILE: /root/siege/siege.log
You can disable this annoying message by editing
the .siegerc file in your home directory; change
the directive 'show-logfile' to false.

Notice the output provides a ton of useful information such as the amount of data transferred, the shortest transaction time, the longest transaction time, the throughput, the total transactions completed, the availability of the web server, the total elapsed time of the siege, and much more. All of the information output by siege would be useful in a report provided to a client who had hired you to test their applications or useful to you if you wanted to know the capacity of a specific web application or web site. You can tweak pretty much any setting you can imagine with siege such as time, users/tasks doing battle, logging, verbosity, etc. If you were really testing new code or a live web application I would imagine you would constantly tweak siege until you were able to determine the exact capacity of the application running on the web server. It is not advised to do so but you could also use siege to perform a Denial of Service or DoS on an application that had limited web server capacity but keep in mind that doing such an attack is illegal.

Siege Man Page: man siege
Click For Siege Man Page


siege – An HTTP/HTTPS stress tester

Siege is a multi-threaded http load testing and benchmarking utility. It was designed to let web developers measure the performance
of their code under duress. It allows one to hit a web server with a configurable number of concurrent simulated users. Those
users place the webserver “under siege.” Performance measures include elapsed time, total data transferred, server response time,
its transaction rate, its throughput, its concurrency and the number of times it returned OK. These measures are quantified and
reported at the end of each run. Their meaning and significance is discussed below. Siege has essentially three modes of opera‚Äê
tion: regression (when invoked by bombardment), internet simulation and brute force.

The format for invoking siege is: siege [options]
siege [options] [url]
siege -g [url]

Siege supports the following command line options:

-V, –version
VERSION, prints the version number

-h, –help
HELP, prints the help section which includes a summary of all the command line options.

-C, –config
CONFIGURATION, prints the current configuration in the $HOME/.siegerc file. Edit that file to set flag values for EVERY
siege run, a feature which eases runtime invocation. You set an alternative resource file with the SIEGERC environment vari‚Äê
able: export SIEGERC=/home/jeff/haha

-v, –verbose
VERBOSE, prints the HTTP return status and the GET request to the screen. Useful when reading a series of URLs from a
configuration file. This flag allows you to witness the progress of the test.

-g, –get
GET, pull down HTTP headers and display the transaction. Great for web server configuration debugging. Requires a URL be
passed to siege on the command line.

-c NUM, –concurrent=NUM
CONCURRENT, allows you to set the concurrent number of simulated users to num. The number of simulated users is limited to
the resources on the computer running siege.

-i, –internet
INTERNET, generates user simulation by randomly hitting the URLs read from the urls.txt file. This option is viable only
with the urls.txt file.

-d NUM, –delay=NUM
DELAY, each siege simulated users sleeps for a random interval in seconds between 0 and NUM.

-b, –benchmark
BENCHMARK, runs the test with NO DELAY for throughput benchmarking. By default each simulated user is invoked with at least a
one second delay. This option removes that delay. It is not recommended that you use this option while load testing.

-r NUM, –reps=NUM, –reps=once
REPS, allows you to run the siege for NUM repetitions. If –reps=once, then siege will run through the urls.txt file one time
and stop when it reaches the end. NOTE: -t/–time takes precedent over -r/–reps. If you want to use this option, make sure
time = x is commented out in your $HOME/.siegerc file.

-t NUMm, –time=NUMm
TIME, allows you to run the test for a selected period of time. The format is “NUMm”, where NUM is a time unit and the “m”
modifier is either S, M, or H for seconds, minutes and hours. To run siege for an hour, you could select any one of the fol‚Äê
lowing combinations: -t3600S, -t60M, -t1H. The modifier is not case sensitive, but it does require no space between the num‚Äê
ber and itself.

-l [FILE], –log[=FILE]
LOG transaction stats to FILE. The argument is optional. If FILE is not specified, then siege logs the transaction to
SIEGE_HOME/var/siege.log. If siege is installed in /usr/local, then the default siege.log is /usr/local/var/siege.log. This
option logs the final statistics reported when siege successfully completes its test. You can edit $HOME/.siegerc to change
the location of the siege.log file.

MARK, mark the log file with a separator. This option will allow you to separate your log file entries with header informa‚Äê
tion. This is especially useful when testing two different servers. It is not necessary to use both the -m option and the
-l option. -m assumes -l so it marks and logs the transaction. If the MESSAGE has spaces in it, make sure that you put it in

HEADER, this option allows you to add additional header information.

RC, sets the siegerc file for the run. This option overrides the environment variable SIEGERC and the default resource file,

-f FILE, –file=FILE
FILE, the default URL file is SIEGE_HOME/etc/urls.txt. To select a different URL file, use this option, i.e., siege -f

-A “User Agent”, –user-agent=”User Agent”
AGENT, use this option to set the User-Agent in the request.

Siege understands the following URL formats:
(brackets indicate the directive is optional)

[protocol://] [:port] [/path/file] POST field=value&field2=value2

Or you can POST the contents of a file using the line input operator, the ”

host/file POST

The first example above is an implicit GET, the next two are obviously POSTs. You can pass parameters using GET much like you would
in a web browser:

If you invoke the URL as a command line argument, you should probably place it in quotes. Currently, it supports two protocols,
http and https. If a protocol is not specified, then siege assumes http. The minimum URL requirement is this: servername. That’s
it. So if you’re in the same domain as a server named shemp and shemp is in your host file or it is in DNS, then: “siege shemp”
will stress (assuming that “index.html” is the server specified index). To stress the same
page using https protocol, the minimum URL requirement is this: https://shemp. That URL specification will lay siege to

To hit multiple URLs, place them in a single file. The default URLs file is $SIEGE_HOME/etc/urls.txt. [You may change that file
with the -f option, see above.] In that file list the URLs one per line:
# place all your comments behind hashes POST scope=a POST a=1&b=2
# POST the contents of a file… POST

When invoked without a URL on the command line, siege looks for URLs in a file. Normally, it reads them all into memory and runs
through them sequentially. If you specify internet mode [-i], then it randomly selects URLs to hit.

You may set and reference variables in URLs file. It is necessary to set them PRIOR to referencing them. The syntax for defining
variables is NAME = VALUE with a single assignment on a single line. If you define several variables in the file, you must place
each assignment on a single line. To use the value of the variable, you must reference it inside $() or ${}, i.e., $(NAME). If you
reference a variable that doesn’t exist, siege will evaluate it to the empty string “”.
# Example using variable assignment
# in the urls.txt file.



Performance measures include elapsed time of the test, the amount of data transferred ( including headers ), the response time of
the server, its transaction rate, its throughput, its concurrency and the number of times it returned OK. These measures are quan‚Äê
tified and reported at the end of each run. The reporting format is modeled after Lincoln Stein’s script:
** Siege 2.60
** Preparing 100 concurrent users for battle.
The server is now under siege…done
Transactions: 339 hits
Availability: 93.39 %
Elapsed time: 67.47 secs
Data transferred: 4273708 bytes
Response time: 8.25 secs
Transaction rate: 5.02 trans/sec
Throughput: 63342.34 bytes/sec
Concurrency: 41.47
Successful transactions: 337
Failed transactions: 26
Longest transaction: 17.77 secs
Shortest transaction: 0.37 secs

The number of server hits. In the example, 25 simulated users [ -c25 ] each hit the server 10 times [ -r10 ], a total of 250
transactions. It is possible for the number of transactions to exceed the number of hits that were scheduled. Siege counts
every server hit a transaction, which means redirections and authentication challenges count as two hits, not one. With this
regard, siege follows the HTTP specification and it mimics browser behavior.

This is the percentage of socket connections successfully handled by the server. It is the result of socket failures (includ‚Äê
ing timeouts) divided by the sum of all connection attempts. This number does not include 400 and 500 level server errors
which are recorded in “Failed transactions” described below.

Elapsed time
The duration of the entire siege test. This is measured from the time the user invokes siege until the last simulated user
completes its transactions. Shown above, the test took 14.67 seconds to complete.

Data transferred
The sum of data transferred to every siege simulated user. It includes the header information as well as content. Because
it includes header information, the number reported by siege will be larger then the number reported by the server. In inter‚Äê
net mode, which hits random URLs in a configuration file, this number is expected to vary from run to run.

Response time
The average time it took to respond to each simulated user’s requests.

Transaction rate
The average number of transactions the server was able to handle per second, in a nutshell: transactions divided by elapsed

The average number of bytes transferred every second from the server to all the simulated users.

The average number of simultaneous connections, a number which rises as server performance decreases.

Successful transactions
The number of times the server responded with a return code < 400. Failed transactions The number of times the server responded with a return code >= 400 plus the sum of all failed socket transactions which
includes socket timeouts.

Longest transaction
The greatest amount of time that any single transaction took, out of all transactions.

Shortest transaction
The smallest amount of time that any single transaction took, out of all transactions.

Jeffrey Fulmer, et al.

Report bugs to Give a detailed description of the problem and report the version of siege that you are using.

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 pub‚Äê
lished by the Free Software Foundation; 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 Foun‚Äê
dation, 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.config(1) urls_txt(5) layingsiege(7)

Siege v2.72 February-17-2012 SIEGE(1)

List Price: $54.99 USD
New From: $33.74 USD In Stock
Used from: $16.41 USD In Stock

List Price: $34.99 USD
New From: $24.95 USD In Stock
Used from: $22.58 USD In Stock

Tags: , , , , , , , , , , , , , , ,
Leave a Reply

*Type the letter/number combination in the abvoe field before clicking submit.