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 format for invoking siege is: siege options… siege 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://] [servername.domain.xxx] [: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 stresshttp://shemp.yourdomain.net/index.shtml ( 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 tohttps://shemp.yourdomain.net/index.shtml 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

http://homer.whoohoo.com/index.shtml

http://homer.whoohoo.com/howto.jsp

http://homer.whoohoo.com/cgi-bin/hello.pl?first=bart&last=simpson

# 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:

http://homer.whoohoo.com/cgi-bin/hello.pl POST name=homer
http://homer.whoohoo.com/haha.jsp 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:

PROT=https://
$(PROT)eos.joedog.org/siege/index.php
$(PROT)eos.joedog.org/wacky/index.php
$(PROT)eos.joedog.org/scout/index.php
$(PROT)eos.joedog.org/libping/index.php
$(PROT)eos.joedog.org/gunner/index.php

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 torture.pl script. This is a sample of siege output:

Ben: $ siege -u shemp.whoohoo.com/Admin.jsp -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 freshmeat.net. 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.

Posted in | 71 Comments

71 Responses to “Siege Manual”

  1. Andy says:

    Hi,

    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 says:

      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 http://www.joedog.org/siege/basic.php
      GET /siege/basic.php HTTP/1.0
      Host: http://www.joedog.org
      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
      Host: http://www.joedog.org
      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

  2. Andy says:

    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

  3. Yogesh Bagul says:

    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 says:

      Yogesh,

      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.

  4. Yogesh Bagul says:

    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…

  5. Jerb says:

    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 says:

      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.

  6. Man Vuong says:

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

    Thanks.

    • Jeff Fulmer says:

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

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

    Luiz

  8. Vipul B says:

    Hi,
    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?

    Thanks
    Vipul B

  9. Valeriy says:

    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:
    Siege:
    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:
    sampler_label,aggregate_report_count,average,aggregate_report_median,aggregate_report_90%_line,aggregate_report_min,aggregate_report_max,aggregate_report_error%,aggregate_report_rate,aggregate_report_bandwidth
    HTTP Request,2875,14,13,16,11,278,0.0,60.816956825249086,2316.683665391714
    TOTAL,2875,14,13,16,11,278,0.0,60.816956825249086,2316.683665391714

    Please advice

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

    Thanks
    Gokul Muralidharan.

  11. Lucas says:

    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…

    Thanks,
    -Lucas

    • Jeff says:

      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 says:

        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 says:

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

  12. deni says:

    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 says:

      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.

  13. Rob says:

    Hi there,

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

    Cheers

    Rob

    • Jeff Fulmer says:

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

      • Rob says:

        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?

  14. Phiri says:

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

    • Jeff Fulmer says:

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

  15. fnux says:

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

    • Jeff says:

      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: http://www.joedog.org/pub/bombard/

      • fnux says:

        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.

  16. DT says:

    Hello Jeff.
    Does Siege support sending the URLs to a proxy? For example,
    URL=http://www.somewebsite.com/dir1/some.html(or any other object)

    Proxy to send the request through= http://www.myproxy.com

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

  17. Jeff says:

    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

  18. Anthony says:

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

  19. Will says:

    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 http://192.168.1.175/image.png
    [error] socket: -1218544832 connection refused.: Connection refused
    [done]

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

    root@ubuntu:~# siege -g http://google.com
    HEAD / HTTP/1.1
    Host: google.com

  20. Ashish says:

    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 http://google.co.in -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
    done.
    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

  21. Aleksandr Demidov says:

    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?

  22. Ondrej Machulda says:

    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?

    Thanks
    OM

    • Ondrej Machulda says:

      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 says:

        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 https://www.google.com/
        CONNECT http://www.google.com:443 HTTP/1.0
        User-agent: Proxy-User

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

        HEAD https://www.google.com:443/ HTTP/1.0
        Host: http://www.google.com
        Accept: */*
        Accept-Encoding:
        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=/; domain=.google.com; HttpOnly
        Server: gws
        X-XSS-Protection: 1; mode=block
        X-Frame-Options: SAMEORIGIN

  23. prasrob says:

    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 says:

      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.

  24. baris kazar says:

    Hi,- Could you please post an example for running POST XML requests? The explanation at http://www.joedog.org/siege-faq#a10
    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.
    Thanks

  25. sagar says:

    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 says:

      Sagar, that’s just an example.

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

      • sagar says:

        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
        password:
        Login incorrect.
        i try to enter password “test123″ but not working.
        The realm is not necessary so i don’t use it.

        • Jeff Fulmer says:

          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 says:

            Yes..it’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”.

  26. Jeremiah says:

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

  27. Himmy says:

    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!

    Cheers,
    Himmy

    • Jeff says:

      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 says:

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

        Cheers
        Himmy

        • Jeff Fulmer says:

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

          • Himmy says:

            Jeff,
            I’m running v.3.0.0

            Cheers
            Himmy

          • Parker says:

            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.

            Thanks!

            % siege -f test.qa.url
            ** 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 test.qa.url

          • Jeff Fulmer says:

            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.

  28. dufei says:

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

  29. tester says:

    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!

  30. XavM says:

    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)

    • Jeff Fulmer says:

      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 says:

        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

        Regards,

        • Jeff Fulmer says:

          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, file.zip 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 says:

            Thank you Jeff for this detailed answer.

            We tried with .zip and it works great :

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

            Thanks again

  31. sieger says:

    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

  32. sharon says:

    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 :(

    • Jeff Fulmer says:

      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]

  33. Tristan says:

    Hi,

    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/10k.zip"
    [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
    FOR A PARTICULAR PURPOSE.

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

    Thanks,
    Tristan

  34. Dhiren says:

    Hi,

    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?

    Regards,
    Dhiren

Leave a Reply