Siege Manual


Introduction ^

Siege is an http/https regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. It lets the user hit a web server with a configurable number of concurrent simulated users. Those users place the webserver “under siege.” The duration of the siege is measured in transactions, the sum of simulated users and the number of times each simulated user repeats the process of hitting the server. Thus 20 concurrent users 50 times is 1000 transactions, the length of the test. 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 quantified and reported at the end of each run. Their meaning and significance is discussed below. Siege has essentially three modes of operation, regression, internet simulation and brute force. It can read a large number of URLs from a configuration file and run through them incrementally ( regression ) or randomly ( internet simulation ). Or the user may simply pound a single URL with a runtime configuration at the command line ( brute force ).

Invocation ^

The formats for invoking siege are: siege <options> and siege <options> [url]

It supports the following command line options:

‘ -V ‘
‘ –version’
Print version information to the screen.

‘ -h ‘
‘ –help’
Print the help section. This presents a summary of the options discussed in this section of the manual.

‘ -C ‘
‘ –config’
Print the current configuration. This option reads your .siegerc file and prints the settings. You can change those settings by editing $HOME/.siegerc. If you don’t have a .siegerc file, then you can generate one by running “siege.config”

‘ -v ‘
‘ –verbose ‘
Verbose output. With this option selected, siege will print transaction information to the screen. This includes HTTP protocol type, the return code and the page it requested:
HTTP/1.1 200 OK: /cgi-bin/whoohoo.cgi?first=Homer&last=simpson
This option is especially useful for charting progress in regression or internet modes when the program is hitting a large number of assorted URLs.

‘ -g URL ‘
‘ –get URL ‘
Get an HTTP transaction. Pull down headers from the server and display HTTP transaction. Great for web application debugging. [Example]

‘ -c NUM ‘
‘ –concurrent=NUM ‘
Concurrent users ( requires argument ). This option allows the user to stress the web server with NUM number of simulated users. The amount is limited only by the computing resources available, but realistically a couple of hundred simulated users is equal to many times that that number in actual user sessions. The number you select represents the number of transactions your server is handling. It does NOT represent the number of concurrent sessions. Remember, real users take some time to actually read the page that they’ve requested….

‘ -i ‘
‘ –internet ‘
This option is used with a configuration file, that is a file containing many URLs. With this option in place, each user randomly hits any one of the URLs in the file each time it hits the server. Much like you can’t tell the users of your website which pages they can view, you have no control over which pages siege will hit in internet mode. With this option set, there is no guarantee that every page in the file will be hit.

‘ -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 following combinations: -t3600S, -t60M, -t1H. The modifier is not case sensitive, but it does require no space between the number and itself.

‘ -f FILE ‘
‘ –file=FILE ‘
The default configuration file, the file with all your URLs is SIEGE_HOME/etc/urls.txt. You can use this option to instruct siege to use a different configuration file: siege –file=serverb.txt

‘ – l ‘
‘ –log ‘
This option instructs siege to log the statistics to SIEGE_HOME/var/siege.log. Each new statistics set is appended to the log.

‘ – m MESSAGE ‘
‘ –mark=MESSAGE ‘
This option allows you to mark the log file with a separator, to differentiate your log file entries with header information. 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 quotes.

‘ -d NUM ‘
‘ –delay=NUM ‘
Each siege simulated user is delayed for a random number of seconds between one and NUM. If you are benchmarking performance, it is recommended that you use a 1 second delay ( -d1 ). The default value is three (3 ). This delay allows for the transactions to stagger rather then to allow them to pound the server in waves.

Configuration File ^

Beginning with version 2.00, siege supports a settings configuration file in which you can store most of your command line options. This makes it much easier to invoke siege and it helps you ensure that every run in a series of runs has the exact same settings. Where is it? The siege configuration file is called .seigerc and it is located in the home directory directory of the user who installed siege. If you did not install siege but you want to use it, then run the command “siege.config”. That will put a template .siegerc file in your home directory. You can edit the settings with your favorite editor. The .siegerc file which is generated by the siege.config utility is well documented with comments describing the directives. Those comments should be all you need to get started.

URL Format ^

Siege understands the following URL format: [protocol://] [] [:portnumber] [/directory/file] Currently, siege only supports http and https protocols. HTTP is the default protocol and therefore does not require a protocol specification. Frankly siege allows you to cheat. The minimum 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 -u shemp will stress ( assuming that is the server specified index ). If you want to lay siege to https servers, then it is necessary to specify the protocol. In the above example, siege -u https://shemp Will lay siege to given the assumptions stated above.

The URLs File ^

In order to run a regression test or an effective internet simulation, you are going to have to run through the URLs on the server you are testing. To accomplish that, place the URLs in a configuration file. The default file is SIEGE_HOME/etc/urls.txt. In that file list the URLs one per line:

# comments behind hashes

# and on and on....

Siege-2.06 and later supports both POST and GET directives. GET directives are constructed as shown above, but POST directives require the POST keyword. Construct POST directives as follows: POST name=homer POST word=doh!&scope=ALL

When invoked without the URL option [ -u URL | –url=URL ], siege looks for URLs in a file. It reads it into memory and runs through the URLs. Normally siege starts at the beginning of the file and works it way through it sequentially. If you specify internet mode [ -i | –internet ], then it selects URLs randomly. An alternative file can be selected at run time with the [ -f FILE | –file=FILE ] option.

Variables ^

Beginning with release 2.57, siege supports variable declaration and evalutation in both the .siegerc file and the urls.txt file. Siege employs variable syntax similar to UNIX shell. They are declared one per line in the file: varname=value To refererence a varaible, you must place it inside $() or ${}. In the example above, type $(varname) to access value. You can use variables to switch between two protocols with one quick edit in your urls.txt file. For example:


Now, in order to switch between https and http, you need only edit one line in the entire file.

Log File ^

When siege is invoked with logging enabled [-l/–log], the program records the transaction in PREFIX/var/siege.log where PREFIX is the directory in which siege was installed. ( see the file INSTALL for instructions. ) The transaction logged is similar to standard output display at the end of every siege run. However, the information is arranged in comma separated text for easy import into a spread sheet. The logging option enables you to maintain history and chart progress over time. In order to group runs by conditions such as URL, server or even protocol, the -m “message”/–mark=”message” option was added. This places the mark “message” in the log file. So that if you switched your testing from http to https, you could mark the log with “start HTTPS testing” -m/–mark assumes logging and makes the -l/–log option unnecessary.

Performance Statistics ^

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 quantified and reported at the end of each run. The reporting format is modeled after Lincoln Stein’s script. This is a sample of siege output:

Ben: $ siege -u -d1 -r10 -c25
..Siege 2.65 2006/05/11 23:42:16
..Preparing 25 concurrent users for battle.
The server is now under siege...done
Transactions: 250 hits
Elapsed time: 14.67 secs
Data transferred: 448000 bytes
Response time: 0.43 secs
Transaction rate: 17.04 trans/sec
Throughput: 30538.51 bytes/sec
Concurrency: 7.38
Status code 200: 250
Successful transactions: 250
Failed transactions: 0

Transactions is the number of server hits. In the example, 25 simulated users [ -c25 ] each hit the server with 10 repetitions [ -r10 ], a total of 250 transactions.

Elapsed time is 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 is 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 internet mode, which hits random URLs in a configuration file, this number is expected to vary from run to run.

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

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

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

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

Successful transactions is the number of times the server returned a code less then 400. Accordingly, redirects are considered successful transactions.

Availabilty ^

New release annoucements are made on To sign up for new release information, click HERE. New versions are available for download via anonymous FTP, click HERE for downloads.

Platforms ^

Multi-threaded siege was built and tested successfully on the following platforms: AIX( powerpc-ibm-aix4.2.1.0 ) Siege has been built and tested successfully using IBM C for AIX version 5. It currently does not support gcc on that platform.

GNU/Linux( i[56]86-pc-linux-gnu ) Siege was originally developed on SuSE GNU/Linux with gcc, there are no known issues on this platform.

HP-UX ( hppa2.0w-hp-hpux11.00 ) Siege has been built on this platform with both the HP ANSI C compiler and gcc.

Solaris( sparc-sun-solaris2.[678] ) Siege LOVES this platform. It was built and tested successfully using gcc.

Microsoft Windows( pc-i686-cygwin ) Siege was ported to Cygwin by Funkman. It runs nicely on all versions greater than or equal to 1.5.

Authors ^

Jeffrey Fulmer, et al — Designed and implemented Siege in his position as Webmaster for Armstrong World Industries

License ^

Please consult the file, COPYING for complete license information. Copyright (C) 2000-2009 Jeffrey Fulmer, et al. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and this permission notice are preserved, thus giving the recipient permission to redistribute in turn. Permission is granted to distribute modified versions of this document, or of portions of it, under the above conditions, provided also that they carry prominent notices stating who last changed them.

  • Andy


    thank you for such a great benchmarking tool! From my tests on the intranet I can say that especiall the ability to test muttiple URLs from a file is tremendous!

    However, I believe there is a bug in your software. When the website is under basic authenticasion a login is not possible. I have set the username and password inside the configfile, but it does not help. I still get a 401 header while trying to access a file with -g.

    I have tried all settings inside the config file and siege is using this file. No luck so far in fixing it. I am using the latest siege build.

    Thank you for any hint on how that could be fixed!

    • Jeff Fulmer

      I am HUGELY skeptical of this claim. Basic authentication has been working for years and that portion of code hasn’t been touched in years.

      Consider the example that is distributed with the source code in the ‘html’ directory: basic.php.

      Inside you’ll find the username is ‘siege’, the password is ‘haha’ and the realm is ‘siege_basic_auth’. This means you’ll set up your .siegerc login like this:

      login = siege:haha:siege_basic_auth

      The realm is not necessary, but if you don’t set a realm then siege will send the login to all realms. Now let’s test it:

      LT $ siege -g
      GET /siege/basic.php HTTP/1.0
      Accept: */*
      Accept-Encoding: gzip
      User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.71b6)
      Connection: close

      HTTP/1.1 401 Authorization Required
      Date: Thu, 16 Feb 2012 13:09:53 GMT
      Server: CERN/1.0A
      X-Powered-By: PHP/5.2.5
      WWW-Authenticate: Basic realm="siege_basic_auth"
      Status: 401 Unauthorized
      Content-Length: 178
      Connection: close
      Content-Type: text/html; charset=WINDOWS-1251

      GET /siege/basic.php HTTP/1.0
      Authorization: Basic c2llZ2U6aGFoYQ==
      Accept: */*
      Accept-Encoding: gzip
      User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.71b6)
      Connection: close

      HTTP/1.1 200 OK
      Date: Thu, 16 Feb 2012 13:09:53 GMT
      Server: CERN/1.0A
      X-Powered-By: PHP/5.2.5
      Content-Length: 278
      Connection: close
      Content-Type: text/html; charset=WINDOWS-1251

  • Andy

    Hi Jeff,

    thank you for your quick reply! It is indeed working,BUT the error was, that I executed the command with root inside the home folder of a user /home/username where the config was. siege seems in that case just to ignore the file or look for one in /home/root

    After switching with su to the user name it worked.

    Best regards

  • Yogesh Bagul

    Hi Jeff,
    Nice tool for closed system testing, In my testbed I want to simulate concurrent users with fixed amount of think time. By my understanding siege provide –delay=NUM option to provide time between successive request from same user(think time) but it generate time randomly between 1 and NUM. Is there is any way to give constant think time value???

    Any help is greatly appreciated.

    • Jeff Fulmer


      It it’s only random. A nice feature would be to add a qualifier similar to the way we handle -t. It could be “c” for constant. –delay=5c Then the delay is always 5 seconds.

  • Yogesh Bagul

    One more thing that I observed in siege is that, actual number of client that generate the load is two times of value provided in input configuration.
    Consider the following case,
    let say service time of server for fixed page is 0.04
    and the server has only one thread, If in input configuration we have set -d=1 and -c2 then by analytical method(transaction rate = 1 /(thinktime+responsetime)) gives value equal to 1.92
    BUT the output produce by siege for transaction rate is 3.75. which is same as if 4 concurrent user accessing server.
    I may be wrong in interpreting it but I am finding all result in same way…

  • Jerb

    In your best estimation what would be a good -c value to represent 40000 unique vistors all requesting a page a the same time ?

    • Jeff Fulmer

      Jerb – My traffic estimates are based on log analyses. Basically, I sample a period of time and obtain the number of unique users. Then I look to see how many page hits those users generated. From that, I can extrapolate the number users necessary to generate x hits per second. -c should correspond with hits.

      It’s not clear over what period of time those 40,000 are visiting. If it’s an hour, then you’re going to need a different tool. If you get that kind of traffic, then you can probably afford Load Runner.

  • Man Vuong

    Thank you very much for the great tool.
    Does Siege support multi-part file POST ? Can I simulate file uploading/downloading with Siege?


    • Jeff Fulmer

      No it doesn’t. I started to work it on that but I couldn’t find an elegant way to incorporate it.

  • Luiz Ravaglio

    Hi Jeff,

    For a regression test, if I include, lets say 3 asp pages, in the URL file and select -c100 (for 100 simulated users), does Siege call the 3 pages sequentially for each simulated user, or it will call one page for each user and turn back to first page? The later means, page 1 user 1, page 2 user 2, page 3 user 3, page 1 user 4 and so on.
    Excuse my poor english.

    Thanks a lot,


  • Vipul B

    Can i use Siege to test load on a Geo Visualization Application. The Application have Maps of Locations just like Google Maps. Is it possible to test it and How?

    Vipul B

    • Jeff Fulmer

      If it runs over http, then siege can test it. I would recommend using sproxy to harvest the URLs.

      • Vipul B

        Thanks Jeff for the Tip.
        I will try my hand over sproxy.

  • Valeriy

    Hello. I am trying to make load testing in two different utilities – JMeter and Siege – and compare results. Testing scenario is simple: There is a file with several URLs. This URL sent to server during several minutes. Both JMeter and Siege runs on *nix server with 8Gb RAM. Java heap memory ~6Gb. There is a huge diffefence between results:
    Lifting the server siege… done. Transactions: 35 hits
    Availability: 100.00 %
    Elapsed time: 15.81 secs
    Data transferred: 0.35 MB
    Response time: 0.02 secs
    Transaction rate: 2.21 trans/sec
    Throughput: 0.02 MB/sec
    Concurrency: 0.04
    Successful transactions: 35
    Failed transactions: 0
    Longest transaction: 0.02
    Shortest transaction: 0.01

    JMeter Aggregate Report:
    HTTP Request,2875,14,13,16,11,278,0.0,60.816956825249086,2316.683665391714

    Please advice

  • Gokul Muralidharan

    Thank you for contributing a great piece of work to the community.

    I have created a huge url file of unique urls of 25k and I would like to get this hit to the server only once at the concurrency rate of 30 / sec at random. When i run

    siege -c30 -d1 -reps=once -i -f ./singleurl.txt

    This does not seems to pick up all the urls (getting random always even -i is not given and in config it is set to off), And hits the same URL multiple times.

    is this is correct, Appreciate your advices.

    Gokul Muralidharan.

    • Gokul Muralidharan

      To clarify further, I need the concurrency but want to avoid hitting the same url twice.

      Gokul Muralidharan.

  • Lucas

    Hi there, quick question:

    I’m finding that when I use Siege to test https connections, Siege doesn’t get past the first query. From strace I can see the request going out from Siege, the server receives the request as expected and a response goes back (its all encypted by ssl so I can’t read it in plain text). But then Siege doesn’t make another request… It’s like it’s waiting for more data or something… Is their a way to put Siege into “very verbose” mode to see what it’s waiting for?

    I wrote the server from scratch, so I’m sure the problem is with my server, but all the other tools I’ve tried (wget, curl, browsers) communicate with the server just fine…


    • Jeff

      If you’re using a version older than 2.73b4, you should be able to get more verbosity with –debug / -D

      In order to make sense of the output it’s best to use -c1 so you only see the output of one client. Let me know how it goes.

      Now about that version. The latest version contains a bug that prevents verbose page output. You can get around that by running -g -D and setting ‘gmethod = GET’ in .siegerc

      I’ll fix that bug in the next version.

      • Carlos

        I’m facing the pretty same issue than Lucas, i.e. siege freezes after sent one request against https url. Then returns zero hits, and TIME OUT error.

        Does anybody is being able to receive success response after a request against https?

        • Jeff

          Carlos: The first thing I would do is eliminate issues with your environment. Can you connect to the server with the openssl client?

  • deni

    thank you so much for benchmarkin tool :D
    its very usefull an d easy to use,,
    by the way,,how do i change the throughput measurement?
    i mean the default result of throughput is in MB/s ,,
    i need the result in KB/s or even in B/s
    how do i configure it?
    thank you so much

    • Jeff

      That’s not a feature of the product so you’ll have to do the match. Multiply megabytes by 1024 to get the number in kilobytes.

  • Rob

    Hi there,

    Was wondering if there were a way to get more detailed per-request timing data out of siege?



    • Jeff Fulmer

      What do you have in mind? If siege doesn’t do it, we’ll take a patch….

      • Rob

        Benchmarking an indexing server with sub-second response times… Was curious if siege had the ability to report response times in intervals smaller that 1/100th of a second?

  • Phiri

    Is there a way of output response times in a unit other than seconds –say milliseconds for instance?

    • Jeff Fulmer

      Phiri – seconds is the only available unit of time. We’re still hopeful that someone will submit a patch that provides more granularity…

  • fnux

    Hi all, and first of all happy new year 2013.

    Siege seems to be a great benchmark toot, but prior to download and install it, I’ve read all your documentation and user manual as well as the multiple posts here.

    However, I’ve three questions/suggestions:

    1) It’s my understanding that the -c parameter is the number of transactions requested by Siege (that is the result of the number of concurrent clients x the number of times the request is made by each concurrent client) but without any explanation about these two numbers. However, wouldn’t be more realistic in a future release to differentiate these two parameters (e.g. -c for the number of clients and -r for the number of repeated requests such as with weighttp)since with the current -c 1000 parameter behavior, this can be one client sending 1000 requests as well as 10 clients sending 100 requests or even 1000 clients sending one request – and that very far to be the same thing!

    2) Further, would it be then possible to include in such a future release a step range (i.e. from 0 to 1000) for the number of concurrent clients that would then allow to simulate a growing load of the server.

    3) Would it also be possible to add a new parameter to indicate the number of threads used by Siege (1 per CPU core is nice).

    e.g. that could then give something like this: siege -d 1 -c 0,1000 -s 10 -r 3 -t 8 -g localhost:8080/index.html where -c 0,1000 is the number of concurrent clients, -s 10 is the step of clients concurrently started, -r 3 is the number of repetition of each request made by each concurrent client and -t 8 is the number of threads of Siege.

    Then, the parameter -t won’t be used anymore except with the old fashion to start Siege.

    What do you think?

    All the best.

    • Jeff

      I think it’s generally pretty good but I’d keep a timed based option. In the meantime, you can do something similar with bombard and that will also allow you to chart your regressions:

      • fnux

        Thank you Jeff for your prompt answer.

        However, I didn’t suggest that you’d delete the current time based option but only that you’d add in a future release another way to make the benchmarks.

        I already know a wrapper made for weighttp that does this king of measures with such kind of parameters that also allows to chart the results.

        However, even if a time based test can be very useful to limit the stress to a certain amount of time, this unfortunately doesn’t explain how the benchmark is done (how many concurrent clients, how many requests sent per client, and how many cores used on any post 2004 CPU architecture unless your tool is a single threaded code) and as a consequence makes very difficult to understand the comparison between different web servers.

        As I already said, 1 client sending 1000 requests or 10 concurrent clients sending 100 requests and even more 1000 concurrent clients sending 1 request is totally different!

        Am I wrong?

        This is why I fairly suggested to add such a second way in a future release.

        All the best.

  • DT

    Hello Jeff.
    Does Siege support sending the URLs to a proxy? For example,
    URL= any other object)

    Proxy to send the request through=

    So basically I am trying to siege my proxy server with a bunch of urls that are not on that server. (This would work similar to curl’s -x option. Also I believe JMeter provides such a functionality as well.)

    Thanks in advance for your response.

  • Jeff

    Yes. Look inside your $HOME/.siegerc file for details. If you don’t have one, you can generate a new one by running: siege.config

  • Anthony

    Jeff, thanks for this insanely useful tool. Could you make a minor tweak and append the longest and shortest transactions to the logfile?

  • Will

    I just downloaded and compiled your tool and I get a weird error. I get connection refused and the tool reports a negative socket number. This is a local server and I can fetch the URL using wget. I do not have any problems when connecting to google, see below:

    root@ubuntu:~# siege -g
    [error] socket: -1218544832 connection refused.: Connection refused

    root@ubuntu:~# wget
    –2013-03-04 11:07:01–
    Connecting to… connected.
    HTTP request sent, awaiting response… 200 OK

    root@ubuntu:~# siege -g
    HEAD / HTTP/1.1

  • Ashish

    I think the tool is better than httperf.

    It ran nicely for me but after some tests I am constantly seeing the error – Error: SIEGEsocket: not readable: Operation now in progress

    Here is the actual dump :-

    siege -u -d1 -r1 -c1 -v
    ** Siege 2.55
    ** Preparing 1 concurrent users for battle.
    The server is now under siege…
    Error: SIEGEsocket: not readable: Operation now in progress
    Transactions: 0 hits
    Availability: 0.00 %
    Elapsed time: 30.36 secs
    Data transferred: 0 bytes
    Response time: -nan secs
    Transaction rate: 0.00 trans/sec
    Throughput: 0.00 bytes/sec
    Concurrency: 0.00
    Successful transactions: 0
    Failed transactions: 1

  • Aleksandr Demidov

    Anthony says:
    February 13, 2013 at 5:12 pm
    “Jeff, thanks for this insanely useful tool. Could you make a minor tweak and append the longest and shortest transactions to the logfile?”
    Yes, support this.
    Dont enough this information in log file. Why its on default not append to log file?

  • Ondrej Machulda

    Hi Jeff,
    thanks for siege, it’s a great tool.

    I’d like to ask – is it possible to run the requests through a proxy? I want to benchmark some service accessible only through proxy (don’t want to test the proxy server itself).

    I noted siege doesn’t respect http_ nor https_proxy system variables. Is there any way how to achieve this?


    • Ondrej Machulda

      Well, I read the previous comments, and if I set the proxy-host in siegerc, the requests to https fails with 404. The requests to :80 appears to work fine. So is it possible to proxy also https traffic?

      • Jeff Fulmer

        It’s theoretically possible. I don’t have the infrastructure for testing that on a regular basis. I’ll look at it when I get a chance.

        UPDATE: Yes.

        LT $ siege -g
        CONNECT HTTP/1.0
        User-agent: Proxy-User

        HTTP/1.0 200 Connection Established
        Proxy-agent: CERN/1.0A

        HEAD HTTP/1.0
        Accept: */*
        User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.74)
        Connection: close

        HTTP/1.0 200 OK
        Date: Thu, 14 Mar 2013 18:23:52 GMT
        Expires: -1
        Cache-Control: private, max-age=0
        Content-Type: text/html; charset=ISO-8859-1
        Set-Cookie: NID=67=mofAaGM8lHv1FruID1t9MY1wTJgD; expires=Fri, 13-Sep-2013 18:23:52 GMT; path=/;; HttpOnly
        Server: gws
        X-XSS-Protection: 1; mode=block
        X-Frame-Options: SAMEORIGIN

  • prasrob

    I’m using this tool to load test mobile site. Is it possible to passing in custom User Agent strings when running the test?

    • Jeff Fulmer

      Yes. See $HOME/.siegerc for details. If you don’t have a $HOME/.siegerc file, run ‘siege.config’ and it will generate one for you.

  • baris kazar

    Hi,- Could you please post an example for running POST XML requests? The explanation at
    is appreciated but it is still not clear.
    I just need to send a few POST XML requests to my server.
    Even one request is fine, too. I can use siege with multiple GET KVP requests.

  • sagar

    How i fix HTTP/1.1 401 authentication.
    I already try with this command
    login = siege:haha:siege_basic_auth but it was not working.

    • Jeff Fulmer

      Sagar, that’s just an example.

      Substitute YOUR username for ‘siege’, YOUR password for ‘haha’ and your (optional) realm for ‘siege_basic_auth’

      • sagar

        Yes, I know jeff i was changed my user/pass when i use this command but there ask me again a password.
        For example:
        login = test123:test123
        Login incorrect.
        i try to enter password “test123″ but not working.
        The realm is not necessary so i don’t use it.

        • Jeff Fulmer

          Is it working in your browser? You may get more enlightening information if you run it in get mode, i.e., siege -g ‘url’

          • sagar

  ’s working on my browser properly..and i also try with your example “login = siege:haha:siege_basic_auth” but i face the same issue When i execute this command “login = siege:haha:siege_basic_auth” immediately ask me a password now in this case which password i have to insert..? i was try with same password which used in HTTP auth like “haha” but it reply me “Login incorrect”.

  • Jeremiah

    How do you exit the process before a test has finished running?

  • Himmy

    I’ve been using you’re tool for a while now and it’s been working brilliantly. But recently I had a problem with one of our tests and found it to be a redirect issue. The one of the urls I hit had a redirect outside of my staging stack. Siege followed the redirect. I’d rather it not do that as I’ll end up stress testing other peoples servers. When I tried to disable following redirects by setting follow-location=false in the .seigerc, siege would exit with “Segmentation Fault” as soon as it hit a url with a redirect as a response.

    Should it be doing this? I’d expect it to simply ignore the redirect response and count the hit and move to the next url.

    Thanks for the invaluable tool again!


    • Jeff

      Look inside $HOME/.siegerc for this directive: follow-location and set it to false:

      follow-location = false

      If you don’t have a $HOME/.siegerc you can generate one by running the command: siege.config

      • Himmy

        Thanks for the prompt reply! I did set follow-location=false but then siege would exit with ‘Segmentation Fault’ when it hits a url with a redirect response.

        I used a small url file, with only two urls, one with a 200 ok and one with a 301 response. When I run with verbose, it shows the url with the redirect but then Segmentation Fault right away.


        • http://joedog Jeff Fulmer

          Which version are you running? I can’t seem to reproduce this.

          • Himmy

            I’m running v.3.0.0


          • Parker

            Hi Jeff,

            Just wanted to add here– I’m seeing the same thing. With follow-location commented out in my .siegerc, everything works fine. But when set to fault, a 302 immedately segfaults.

            I’m on 3.0.2, output follows.


            % siege -f
            ** SIEGE 3.0.2
            ** Preparing 15 concurrent users for battle.
            The server is now under siege…
            HTTP/1.1 302 0.03 secs: 0 bytes ==> GET /img_redirect/12345?width=100&height=100
            zsh: segmentation fault siege -f

          • http://joedog Jeff Fulmer

            This was fixed in the 3.0.3 betas. Version 3.0.3 will be released soon. Unless something surfaces, the latest beta should be considered a 3.0.3 final release.

  • dufei

    The -u option sometimes work and sometimes not work. It is very strange.
    eg. siege -u
    and the siege point out: siege: invalid option — u
    my siege version is 2.72

    • http://joedog Jeff Fulmer

      What do you expect to happen when you select -u ?

  • tester

    Just a feature request: add a command-line swithch to disable the (dark blue) progess message:

    HTTP/1.1 200 0.00 secs: 1024 bytes ==> /1k.htm

    This unreadable for me (dark blue on black…) and it also slows down the test needlessly.

    Keep up the good work!

    • http://joedog Jeff Fulmer

      You can turn off verbose or you can run siege with -q/–quiet

      I’ll consider an option to turn off color.

  • XavM

    Hi there,

    We are trying to use siege to post a protobuf payload

    siege -g “http://host/route-request POST <./payload.protobuffed"

    It seams that siege is doing some 'transformation' on the payload before sending it ans throws a 'Malformed message' error on the server side

    Is there any way to make siege send the actual payload ?
    (CF: Why does siege POST data that is smaller than the size of my post file)

    • http://joedog Jeff Fulmer

      It’s probably trimming leading or trailing white space from the file. Is this ASCII or binary? Maybe we have a bug. Send me an email jeff at thisdomain dot org (if you can’t figure out that anti spam interpretation, click the support link at the top)

      • XavM

        I guess I did something wrong when sending you the eMail

        Here is its content :

        Thank you for your reply.

        The file containing the PROTOBUF payload is binary .

        Is there any way to tell Siege to send binary data with no trimming ?

        eg : Some kind of curl equivalent to “–data-binary” :

        curl -X POST –data-binary @./payload.protobuffed http://host/route-request


        • http://joedog Jeff Fulmer

          Sorry, I was rushed. I should have provided a better answer. Because it’s reading from a file, it’s necessary to switch to binary mode when it’s a binary file. If the file is binary, siege reads it in that mode and it doesn’t trim the file.

          So how does it tell what’s binary and what’s ASCII? Siege takes its cue from the file extension. If you rename it file.jpg, or another obvious binary extension, you should be able to get your work done. You can view the complete list of extensions inside src/load.c (You want to select an extension that is listed as FALSE).

          • XavM

            Thank you Jeff for this detailed answer.

            We tried with .zip and it works great :

            siege -g “http://host/route-request POST <./"

            Thanks again

  • sieger

    is there any way to do multiple GET requests per connection?

    If i have 4 urls in my url.txt, I want all 4 to be requested in one TCP connection and do this for 100 concurrent users.. Is this possible

  • sharon

    Hi im testing this tool and it looks great, but i have a littile problem when i run the siege -g (my site requires basic authentication) its returning the 200, but when i try to run the urls from a file i only get 401 responses, i added the login to the .siegrc file im running it from the home of my user , im lost dont know what to do :(

    • http://joedog Jeff Fulmer

      From an authentication perspective, siege doesn’t care if the URL comes from a file or from the command line. First, let’s make sure you’re using that file. Run this command and look at the output:

      siege -f /path/to/urls.txt -C

      (That’s a capital “C”). You should see the login credentials at the end of the output. It will be formatted like this:

      username:password [basic realm]

  • Tristan


    I’m getting seg faults when running siege on my Mac (installed via homebrew on OS X 10.9.1):
    ➜ /tmp siege -v -g “http://somehost:8080/file/5e0eae64-92a4-47d5-b9de-074110afb176/10k.txt POST </tmp/"
    [1] 37925 segmentation fault siege -v -g
    ➜ /tmp siege –version
    SIEGE 3.0.5

    Copyright (C) 2013 by Jeffrey Fulmer, et al.
    This is free software; see the source for copying conditions.
    There is NO warranty; not even for MERCHANTABILITY or FITNESS

    I'm trying to POST a binary file as the request body to my rest API. Any help would be appreciated.


  • Dhiren


    Thanks for such a wonderful tool.

    Just wanted to know about the -b option with siege its a benchmarking option thats all i could find out. but wat are the default parameters that are taken if you use the -b option?


    • http://joedog Jeff Fulmer

      -b could probably have a better distinction. It’s basically a shortcut for -d 0

  • Sai

    How can this be used to test for a proxy server instead of a web server?

  • Pingback: Load & Stress Testing | Cloud Like a Pro()


    We’ll have a look at the engine, and carquest shop online
    will be stopping for gas less often. And we’re like, yeah, that’s the wrong
    one, here we go, we are racing a Honda factory
    team that is bringing– MIKE MUSTO: An Odyssey minivan.

  • Jimmy

    Hi, can you please tell me how can i post JSON objects?
    I have a json like this:
    ‘username’ : usr,
    ‘password’ : pw

    I tryed something like this, but did not work:
    siege -H ‘Content-Type:application/json’ “http://localhost/login.php POST {‘username’ : usr,’password’ : pw}”

    I use the latest version (3.0.5) and run it on ubuntu.

    • http://joedog Jeff Fulmer

      Nothing stands out as wrong with that. What does ‘did not work’ mean? Here’s an example with basically the same syntax:

      LT $ siege -g -H “Content-type: application/json” “ POST {‘username':user, ‘password':pwd}”
      POST / HTTP/1.0
      Accept: */*
      User-Agent: Mozilla/5.0 (pc-i686-cygwin) Siege/3.0.6
      Content-type: application/json
      Connection: close
      Content-type: application/x-www-form-urlencoded
      Content-length: 33

      {‘username':user, ‘password':pwd}

      HTTP/1.1 200 OK

      You could always put the json in a file and call it like this:

      siege -g “ POST

      (If you call it .json, siege will set “application/json”)

  • Vladimir

    Thank you for your tool, it’s really cool, but I still can’t get one thing: is it possible in Siege to create multiple users who will act simultaneously, but log in with different credentials, and if it is, than how I should do that?

    Thank you for your kind attention.

    • http://joedog Jeff Fulmer

      You can sort of achieve this by selectively crafting your urls.txt file. If you want ten different users, just load ten different logins at the top of the file. Siege will run the list incrementally with each thread picking up a different URL.

  • ask870

    Hello, Jeff

    The siege -c 1300, it’s doesn’t work, Thks

    # siege -b -c 1500 -t 2m -i -f /mnt/urlist.outdoor
    ** SIEGE 3.0.0
    ** Preparing 1500 concurrent users for battle.
    The server is now under siege…Segmentation fault

    my OS:
    # ulimit -a
    core file size (blocks, -c) 0
    data seg size (kbytes, -d) unlimited
    scheduling priority (-e) 0
    file size (blocks, -f) unlimited
    pending signals (-i) 399360
    max locked memory (kbytes, -l) 32
    max memory size (kbytes, -m) unlimited
    open files (-n) 65535
    pipe size (512 bytes, -p) 8
    POSIX message queues (bytes, -q) 819200
    real-time priority (-r) 0
    stack size (kbytes, -s) 10240
    cpu time (seconds, -t) unlimited
    max user processes (-u) 16384
    virtual memory (kbytes, -v) unlimited
    file locks (-x) unlimited

    siege -c <= 1300 it's good

    # siege -b -c 1300 -t 5s -i -f /mnt/urlist.outdoor
    ** SIEGE 3.0.0
    ** Preparing 1300 concurrent users for battle.
    The server is now under siege…
    Lifting the server siege… done.

    Transactions: 604 hits
    Availability: 100.00 %
    Elapsed time: 4.38 secs
    Data transferred: 1.77 MB
    Response time: 2.28 secs
    Transaction rate: 137.90 trans/sec
    Throughput: 0.40 MB/sec
    Concurrency: 313.97
    Successful transactions: 604
    Failed transactions: 0
    Longest transaction: 3.76
    Shortest transaction: 0.00

  • roro

    Hi Jeff,

    I’m running siege in cygwin 32 bit, with SSL.

    When hitting an https server with this call, I’m getting a negative socket and connection refused:


    Any idea why that’s happening? here’s the output:

    [error] socket: -2147248824 connection refused.: Connection refused

    • http://joedog Jeff Fulmer

      No idea. What do you see in the webserver’s logs?

  • roshni

    Hi jeff,

    I need your help regarding running urls in a file containing post directives. Could you please send me some eg. with a little discription of how i should create a urls.txt file and run it to test thousand urls and each hitted once only.
    Eagerlly waiting for you responce.


  • Snooops

    Hey Guys,
    im running siege 3.0.9 with:
    siege -c10 -r once -f urls2.txt -b

    i get a lot of:
    [alert] socket: -1210620160 select timed out: Connection timed out

    Successful transactions: 264
    Failed transactions: 23

    ulimit -n says: 1024000
    net.core.somaxconn = 20000

    thats really not huge – and i know that the server can handle more ( and so on) What can i do to make sure siege is running well.

    • http://joedog Jeff Fulmer

      Ten isn’t a large number of concurrent users so you’re probably not opening more connections than you have server handlers (which is a common problem).

      But that doesn’t mean you don’t have an issue. A possible cause of this could be that some handlers are waiting for a resource, i.e., database connection, file locking, thread locking, etc. If it takes longer than 30 seconds to respond, then siege will timeout the connection.

      You can play with the timeout value in $HOME/.siegerc to see if it helps shed light on this.

  • Oleg

    Hello. Are the response time is the same as TTFB?