Siege is a powerful, open-source HTTP load testing and benchmarking utility. It’s designed to help web developers and system administrators measure the performance of their code and infrastructure under stress. With Siege, you can simulate multiple users accessing your web server simultaneously, allowing you to identify bottlenecks and ensure your application can handle real-world traffic. Siege supports basic authentication, cookies, and the HTTP, HTTPS, and FTP protocols.

Why Use Siege?

  • Simulate Real-World Load: Siege allows you to simulate a configurable number of concurrent users, mimicking real-world traffic patterns.
  • Identify Performance Bottlenecks: By subjecting your server to heavy load, you can pinpoint areas where performance degrades, such as slow database queries or inefficient code.
  • Measure Application Resilience: See how your application behaves under stress and identify potential failure points.
  • Benchmarking: Compare the performance of different hardware configurations, software versions, or code optimizations.
  • Easy to Use: Siege offers a straightforward command-line interface, making it easy to get started with load testing.

Installation Procedure

Before installing Siege, ensure you have the necessary prerequisites:

On CentOS/RedHat:

sudo yum install gcc make

On Ubuntu/Debian:

sudo apt-get install gcc make

Installation Steps:

Download the Siege source code from a trusted source (e.g., the official Siege website or a reliable mirror). Then, follow these steps:

$ ./configure
$ make
$ sudo make install

During the configure step, you may encounter dependency issues. Address them using your system’s package manager (yum or apt-get). For example, if configure complains about missing OpenSSL libraries, install them:

sudo yum install openssl-devel  # CentOS/RedHat
sudo apt-get install libssl-dev  # Ubuntu/Debian

After a successful installation, the following files will be installed:

siege          -->    SIEGE_HOME/bin/siege
bombardment    -->    SIEGE_HOME/bin/bombardment
siege2csv      -->    SIEGE_HOME/bin/siege2csv
.siegerc       -->    $HOME/.siegerc
siege.1        -->    SIEGE_HOME/man/man1/siege.1
bombardment.1  -->    SIEGE_HOME/man/man1/bombardment.1
siege2csv.1    -->    SIEGE_HOME/man/man1/siege2csv.1
layingsiege.1  -->    SIEGE_HOME/man/man1/layingsiege.1
urls_text.1    -->    SIEGE_HOME/man/man1/urls_txt.1
urls.txt       -->    SIEGE_HOME/etc/urls.txt

SIEGE_HOME typically defaults to /usr/local. You can find out the exact location by running which siege.

Understanding the Files

  • siege: The main Siege executable.
  • bombardment: A utility for sending HTTP requests based on a configuration file.
  • siege2csv: A script for converting Siege output to CSV format for easier analysis.
  • .siegerc: The Siege configuration file. This file allows you to customize Siege’s behavior, such as setting the number of concurrent users, the delay between requests, and the location of the log file.
  • urls.txt: A file containing a list of URLs to test. Siege can read URLs from this file and hit them randomly.

Usage: The siege Command

To get a quick overview of the siege command’s options, simply run:

siege

This will display the usage information:

SIEGE 3.0.9
Usage: siege [options]
       siege [options] URL
       siege -g URL
Options:
  -V, --version             VERSION, prints the version number.
  -h, --help                HELP, prints this section.
  -C, --config              CONFIGURATION, show the current config.
  -v, --verbose             VERBOSE, prints notification to screen.
  -q, --quiet               QUIET turns verbose off and suppresses output.
  -g, --get                 GET, pull down HTTP headers and display the
                            transaction. Great for application debugging.
  -c, --concurrent=NUM      CONCURRENT users, default is 10
  -i, --internet            INTERNET user simulation, hits URLs randomly.
  -b, --benchmark           BENCHMARK: no delays between requests.
  -t, --time=NUMm           TIMED testing where "m" is modifier S, M, or H
                            ex: --time=1H, one hour test.
  -r, --reps=NUM            REPS, number of times to run the test.
  -f, --file=FILE           FILE, select a specific URLS FILE.
  -R, --rc=FILE             RC, specify an siegerc file
  -l, --log[=FILE]          LOG to FILE. If FILE is not specified, the
                            default is used: PREFIX/var/siege.log
  -m, --mark="text"         MARK, mark the log file with a string.
  -d, --delay=NUM           Time DELAY, random delay before each requst
                            between 1 and NUM. (NOT COUNTED IN STATS)
  -H, --header="text"       Add a header to request (can be many)
  -A, --user-agent="text"   Sets User-Agent in request
  -T, --content-type="text" Sets Content-Type in request

Diving Deeper: Key Options

Here’s a breakdown of some of the most commonly used siege options:

  • -c, –concurrent=NUM: Specifies the number of concurrent users to simulate. This is a crucial parameter for load testing.
  • -t, –time=NUMm: Sets the duration of the test. The m modifier can be S (seconds), M (minutes), or H (hours). For example, -t 10M runs the test for 10 minutes.
  • -r, –reps=NUM: Specifies the number of times to repeat the test. This is useful for averaging results across multiple runs.
  • -f, –file=FILE: Specifies a file containing a list of URLs to test. Each line in the file should contain a URL.
  • -H, –header=”text”: Adds a custom HTTP header to the request. Useful for testing APIs that require specific headers, such as Content-Type or Authorization.
  • -A, –user-agent=”text”: Sets a custom User-Agent header.
  • -b, –benchmark: Runs the test in benchmark mode, with no delays between requests. This can help to maximize the load on the server.
  • -l, –log[=FILE]: Logs the output of the test to a file. If no filename is specified, Siege will use the default log file (PREFIX/var/siege.log, where PREFIX is typically /usr/local).
  • -v, –verbose: Enables verbose output, providing more detailed information about the test.
  • -q, –quiet: Suppresses output.
  • -g, –get URL: Performs a GET request to the specified URL and displays the headers. This is a useful debugging tool.

Basic Usage Examples

Testing a GET Request

To simulate 100 concurrent users making 100 requests to http://example.com/, use the following command:

siege http://example.com/ -c 100 -r 100

Testing a POST Request

To send a POST request with a JSON payload, use the following command:

siege -H 'Content-Type:application/json' "http://example.com/ POST < ./data.json" -c 10 -r 1000

In this example:

  • -H 'Content-Type:application/json' sets the Content-Type header to application/json.
  • "http://example.com/ POST < ./data.json" specifies the URL and indicates that the POST data should be read from the data.json file.

Example data.json:

{
  "key1": "value1",
  "key2": "value2"
}

Using a URLs File

Create a file named urls.txt with a list of URLs, one per line:

http://example.com/page1
http://example.com/page2
http://example.com/page3

Then, run Siege with the -f option:

siege -f urls.txt -c 50 -t 1M

This will simulate 50 concurrent users accessing the URLs in urls.txt randomly for 1 minute.

Configuration File (.siegerc)

The .siegerc file in your home directory ($HOME/.siegerc) allows you to customize Siege’s default behavior. You can set options such as:

  • concurrent: The default number of concurrent users.
  • delay: The default delay between requests.
  • logfile: The default log file location.
  • verbose: Whether to enable verbose output by default.

Example .siegerc:

concurrent = 25
delay = 1.0
logfile = /var/log/siege.log
verbose = true

You can find a sample .siegerc file in the Siege documentation or online.

Further Reading

For more detailed information, consult the man pages:

man siege
man layingsiege
man siege.config

All the Siege man pages are also available online:

http://www.joedog.org/siege/docs/man/index.html

Or, read the HTML manual:

http://www.joedog.org/siege/docs/manual.html

By using Siege effectively, you can gain valuable insights into the performance and resilience of your web applications, allowing you to optimize them for real-world usage. Remember to always test responsibly and avoid overloading production systems.