JoeDog/siege: an HTTP load tester for developers and sysadmins

What siege does, and who actually needs it

Siege is an open source regression test and benchmark utility. It can stress test a single URL with a user defined number of simulated users, or read many URLs into memory and stress them simultaneously. The program reports the total number of hits recorded, bytes transferred, response time, concurrency, and return status. That report is the whole product. There is no dashboard, no graph, no agent to install on the target.

The README frames the audience directly: siege was written for both web developers and web systems administrators, so they can test their programs and their systems under duress. The use case is a server you control and a question you cannot answer from logs alone, such as whether the site survives 400 simultaneous transactions when it currently peaks at 250.

One design decision shapes every result. The README notes that human users take time to digest the data which comes back to them, while siege users do not. The author states that 400 simultaneous siege users translates to at least five times that amount in real internet sessions. That is why the tool offers a delay option, and why a raw siege number should never be read as a headcount of real visitors.

How siege models load: sockets, transactions, and the delay knob

A transaction is characterised in the README as the server opening a socket for the client, handling a request, serving data over the wire, and closing the socket upon completion. Siege counts those transactions and times each one, then reports transaction rate and concurrency alongside the totals.

Configuration is per user, and most features are command line options with default values, so a minimal invocation stays short. Siege supports HTTP/1.0 and 1.1, the GET and POST directives, cookies, transaction logging, and basic authentication. URLs can be fed in from a file and held in memory, which is what makes the many-URL mode different from a single-URL loop.

The delay option is the closest thing siege has to traffic shaping. When set, each siege user sleeps for a random number of seconds between 1 and NUM. The README recommends taking the average amount of time spent on a page from your server logs and using that number as the delay. This is a coarse model: a uniform random sleep is not a real think-time distribution, and it does nothing for the shape of a traffic spike. It only stops siege from behaving like a machine that never pauses.

Installing siege from source and running a first test

The README points to an anonymous FTP tarball at download.joedog.org and to the GitHub repository, and says siege was built with GNU autoconf. If you are familiar with GNU software, the README says you should be comfortable installing siege, and it defers detail to the INSTALL file.

The prerequisites are compile-time only. To enable HTTPS support you must install both openssl and openssl-devel. To enable gzip transfer encoding you need both zlib and zlib-devel. The README is explicit that these are not dependencies: if the libraries are not present, the application will still compile and function, it simply will not contain those functionalities. If you add the libraries after siege has been compiled, you have to run ./configure, make and make install again.

A source build therefore looks like the following. The bootstrap script is the one the repository's own Dockerfile runs before configure, and it is what generates the autoconf build files from a git checkout.

git clone https://github.com/JoeDog/siege.git
cd siege
utils/bootstrap
./configure
make
make install

If you would rather not build on your own machine, the repository ships a Dockerfile that does the same work in two stages. It takes build arguments for the base image and for the siege version, and the run stage copies /usr/local/ from the builder and sets the entrypoint to siege.

ARG OS_VER=20.04
ARG OS_IMAGE=ubuntu
FROM ${OS_IMAGE}:${OS_VER} AS builder
ARG SIEGE_VER=v4.1.5
ARG SIEGE_REPO=https://github.com/JoeDog/siege.git
ENTRYPOINT ["siege"]

Note the version argument in that file: it defaults to v4.1.5, while the most recent release listed for the project is v.2.4.0. The Dockerfile does not explain the numbering, and the README does not either, so treat the tag in the Dockerfile as something to check rather than something to assume.

For a first real run, the shape of the command is a URL plus a user count and a repetition count. The README describes the model as stress a web server with n number of users t number of times, where n and t are defined by the user. After the run you get transactions, elapsed time, bytes transferred, response time, transaction rate, concurrency, and the number of times the server responded OK, meaning status code 200. Read the concurrency figure and the 200 count first; a high transaction rate with a falling 200 count is a server failing, not a server performing.

Where siege is the wrong tool

The most important limitation is stated by the README itself, in the prerequisites section. HTTPS and gzip are optional at compile time, and a build without openssl or zlib is a valid, working build with those capabilities missing. Nothing in the output tells you which build you have. If you benchmark an HTTPS endpoint with a binary compiled without openssl, you are not measuring the thing you think you are measuring.

The second limitation is the traffic model. Siege opens a socket, sends a request, reads the response, and closes. It does not parse HTML, fetch subresources, execute JavaScript, or maintain a browser session across pages unless you drive it with cookies and a URL list you wrote yourself. A page that looks cheap to siege can be expensive in a browser, and a page that looks expensive to siege can be cheap in a browser that caches aggressively.

Third, the reporting is a text summary at the end of a run. There is no time series, no per-second breakdown, and no way to correlate a latency spike with a moment during the test from siege's own output. If you need that, you are pairing siege with something else, and the README does not describe that workflow.

Finally, siege is a load generator, not a correctness test. It reports status codes. It does not tell you whether the response body was right.

Siege against ApacheBench and wrk

The obvious comparison is ApacheBench, usually shipped as ab. Both are command-line HTTP load generators, and both report throughput and latency. The difference is scope. ApacheBench is built around a single URL per invocation and is distributed with the Apache HTTP Server tooling. Siege reads many URLs into memory and stresses them simultaneously, which is the need the README says siege was born out of: the author modelled it in part after Lincoln Stein's torture.pl, but torture.pl does not allow one to stress many URLs simultaneously.

Against wrk, the split is different again. wrk is a modern multi-threaded benchmark tool with a scripting layer for custom request generation. Siege is single-process in design and configures behaviour through command line options and a URL file rather than a script. If your test needs to compute a request body per iteration, siege's POST directive and transaction logging are the extent of what the README describes.

There is also a licensing difference worth noting. Siege is GPL-3.0. If you are embedding a load generator inside a product rather than running it as a standalone tool, that matters, and the README points to COPYING for the full terms.

Maintenance, upgrades, and the licence terms

The repository is not archived, and the last push was on 2026-08-18, the same date as the v.2.4.0 release. That is recent, but the release history is thin: v.2.4.0 is the only release listed here, and the README's copyright line still reads 2000-2023. A project that pushes occasionally and tags rarely is not abandoned, but it is also not moving quickly, and you should expect to read the ChangeLog rather than release notes when you upgrade.

Upgrade cost is dominated by the build. Because HTTPS and gzip are compile-time switches, every upgrade is a chance to silently lose a capability if the build host no longer has openssl-devel or zlibg-dev present. The README's own instruction is to rerun ./configure, make and make install after adding the libraries, which tells you the build is not hermetic. Pin your build environment, or use the Dockerfile, which installs zlib1g-dev in the builder stage.

On licensing: siege is GPL-3.0, and the README directs readers to the COPYING file for complete terms. The README also records a special exception allowing the code to be linked with the OpenSSL library under conditions described in each source file. That exception exists because of a licence incompatibility between OpenSSL and the GPL, and it is the kind of clause that matters if you redistribute a modified siege. This is a description of what the files say, not legal advice; read COPYING and the per-file notices yourself.

Editorial conclusion

Adopt siege if you are a developer or sysadmin who needs a small, scriptable load generator for a server you control, and you are comfortable building from source with autoconf. Do not adopt it if you need a maintained binary package, a web dashboard, or a tool that models real browser behaviour. Before you trust a run, verify that HTTPS and gzip support are actually compiled in (the README says the program builds and runs without them), and check the delay value against the average time your server logs show for a page.

Frequently asked questions

Official sources

1. Issues
2. JoeDog/siege on GitHub
3. License: GPL-3.0
4. README
5. Releases