Siege: How to Benchmark Your Server

What is Siege?

Siege is a remote host http/https regression testing and benchmarking tool that can be used to test the performance of your web server under duress to see how it will perform.

It allows an admin or server owner to simulate hits or connections to a web server with a preconfigured number of concurrent connections from simulated users. By utilizing this software, these simulated users target the server and place it “under siege,” hence the name. The timeframe of the siege is measured in:

Transactions
The number of simulated users
The number of times each faux user repeats the process of trying to connect to the server

Thus, if 20 simulated users make 50 concurrent requests, this would equal 1000 events.

Performance measurements include:

The elapsed time frame of the test
The amount of info transferred
The response time of the server
The transaction rate
The throughput
The level of concurrency
The number of times it returned a 200 OK response

These actions and outputs are reported and quantified at the end of every operation. The significance and meaning of the data can then be reviewed, and corresponding actions taken to address any issues found.

Siege has essentially three modes of operation:

Regression
Internet simulation
Brute Force

Siege can utilize a considerable number of URLs listed in a configuration file and work through them incrementally (in regression testing mode) or randomly (in the internet simulation mode). Additionally, the user may simply hit a single URL via the command line (in brute force mode).

Syntax

[root@host ~]# siege <options> and siege <options> [url]

[root@host ~]# siege -c10 -r20 google.com

In the example above, Siege will hit the servers at Google with 10 concurrent users, 20 times to run the test.

All available options:

Usage

siege [option]
siege [options] URL
siege -g URL

Options	NAME	DESCRIPTION
-V, –version	VERSION	Prints the version number.
-h, –help	HELP	Prints this section.
-C, –config	CONFIGURATION	Shows the current config.
-v, –verbose	VERBOSE	Prints notification to screen.
-g, –get	GET	Pulls down HTTP headers and displays the transaction. Great for application debugging.
-c, –concurrent=NUM	CONCURRENT	Number of concurrent users. The default is 10.
-i, –internet	INTERNET	Internet user simulation, which hits URLs randomly.
-b, –benchmark	BENCHMARK	Benchmark: no delays between requests.
-t, –time=NUMm	TIMED	Timed testing with modifiers: S (seconds), M (minutes), or H (hours). Ex. –time=1H is a one-hour test.
-r, –reps=NUM	REPS	Number of times to run the test.
-f, –file=FILE	FILE	Selects a specific URL’s file.
-R, –rc=FILE	RC	Specify a siegerc file.
-l, –log[=FILE]	LOG	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	DELAY	Random time delay before each request 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.

Installation

CentOS

In CentOS 7, we simply yum install Siege.

[root@host ~]# yum install siege
Loaded plugins: fastestmirror, priorities, tmprepo
Determining fastest mirrors
epel/x86_64/metalink                                  |  16 kB  00:00:00
 * base: mirrors.liquidweb.com
 * epel: mirrors.liquidweb.com
 * extras: mirrors.liquidweb.com
 * updates: mirrors.liquidweb.com
base                                                  | 3.6 kB  00:00:00
epel                                                  | 5.4 kB  00:00:00
extras                                                | 2.9 kB  00:00:00
group_spacewalkproject-java-packages                  | 3.3 kB  00:00:00
nodesource                                            | 2.5 kB  00:00:00
spacewalk                                             | 3.6 kB  00:00:00
updates                                               | 2.9 kB  00:00:00
(1/4): epel/x86_64/updateinfo                         | 1.0 MB  00:00:00
(2/4): epel/x86_64/primary_db                         | 6.9 MB  00:00:00
(3/4): updates/7/x86_64/primary_db                    | 5.8 MB  00:00:00
(4/4): nodesource/x86_64/primary_db                   |  27 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package siege.x86_64 0:4.0.2-2.el7 will be installed
--> Processing Dependency: libjoedog >= 0.1.2 for package: siege-4.0.2-2.el7.x86_64
--> Running transaction check
---> Package libjoedog.x86_64 0:0.1.2-1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================
 Package               Arch         Version             Repository       Size
=====================================================================================
Installing:
 siege                 x86_64       4.0.2-2.el7         epel             108 k
Installing for dependencies:
 libjoedog             x86_64       0.1.2-1.el7         epel              19 k

Transaction Summary
=====================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 126 k
Installed size: 278 k
Is this ok [y/d/N]: y

Downloading packages:
(1/2): libjoedog-0.1.2-1.el7.x86_64.rpm                          |  19 kB  00:00:00
(2/2): siege-4.0.2-2.el7.x86_64.rpm                              | 108 kB  00:00:00
------------------------------------------------------------------------------------
Total                                                   1.9 MB/s | 126 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libjoedog-0.1.2-1.el7.x86_64                    1/2 
  Installing : siege-4.0.2-2.el7.x86_64                        2/2 
  Verifying  : libjoedog-0.1.2-1.el7.x86_64                    1/2 
  Verifying  : siege-4.0.2-2.el7.x86_64                        2/2 

Installed:
  siege.x86_64 0:4.0.2-2.el7

Dependency Installed:
  libjoedog.x86_64 0:0.1.2-1.el7

Complete!
[root@host ~]#

Ubuntu

For a Ubuntu server, we use apt-get to install Siege.

root@host:~# apt-get install siege
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  siege
0 upgraded, 1 newly installed, 0 to remove and 29 not upgraded.
Need to get 0 B/98.3 kB of archives.
After this operation, 278 kB of additional disk space will be used.
Selecting previously unselected package siege.
(Reading database ... 252416 files and directories currently installed.)
Preparing to unpack .../siege_4.0.4-1build1_amd64.deb ...
Unpacking siege (4.0.4-1build1) ...
Setting up siege (4.0.4-1build1) ...
Processing triggers for man-db (2.8.7-3) ...
root@host:~#

Testing

We will use the command noted above as a test example.

Ubuntu

root@host:~# siege -c10 -r20 google.com
New configuration template added to /root/.siege
Run siege -C to view the current settings in that file
** SIEGE 4.0.4
** Preparing 10 concurrent users for battle.
The server is now under siege...
Transactions:		         600 hits
Availability:		      100.00 %
Elapsed time:		        4.53 secs
Data transferred:	        4.12 MB
Response time:		        0.07 secs
Transaction rate:	      132.45 trans/sec
Throughput:		        0.91 MB/sec
Concurrency:		        9.40
Successful transactions:         600
Failed transactions:	           0
Longest transaction:	        0.34
Shortest transaction:	        0.02
 
root@host:~#

CentOS

[root@host ~]# siege -c10 -r20 google.com
New configuration template added to /root/.siege
Run siege -C to view the current settings in that file
** SIEGE 4.0.2
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200     0.07 secs:   49183 bytes ==> GET  /
HTTP/1.1 200     0.07 secs:   49202 bytes ==> GET  /
HTTP/1.1 200     0.07 secs:   49177 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49188 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49214 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49199 bytes ==> GET  /
HTTP/1.1 200     0.07 secs:   49195 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49227 bytes ==> GET  /
HTTP/1.1 301     0.02 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 301     0.03 secs:     219 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   48870 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49181 bytes ==> GET  /
HTTP/1.1 200     0.08 secs:   49192 bytes ==> GET  /
HTTP/1.1 200     0.07 secs:   49227 bytes ==> GET  /

Transactions:		         600 hits
Availability:		      100.00 %
Elapsed time:		        8.25 secs
Data transferred:	       10.47 MB
Response time:		        0.05 secs
Transaction rate:	       72.73 trans/sec
Throughput:		        1.27 MB/sec
Concurrency:		        3.41
Successful transactions:         600
Failed transactions:	           0
Longest transaction:	        0.16
Shortest transaction:	        0.02
 
[root@host ~]#

Performance Statistics

Transactions: This is the number of times the server is hit.
Elapsed time: This is the time span of the entire test. The result of this output is measured from the moment the admin invokes Siege until the final simulated user completes its transaction.
Data transferred: This is the total amount of data conveyed with each of Siege’s simulated users. This result will include the header info. Because it incorporates the header info, the result reported to Siege will be larger than the numbers reported by the server. If we are in internet mode, which pushes the random URLs from the configuration file, this number will vary from test to test.
Response time: This is the average amount of time it takes to respond to each simulated request.
Transaction rate: This is the average quantity of transactions the server was able to handle per second. In essence: transactions/elapsed time.
Throughput: This is the average amount of bytes transferred from the server every second to all of the simulated users.
Concurrency: This is the average number of concurrent connections, which is a number that increases as the server’s performance decreases.
Successful transactions: This number indicates the number of times the server returned an error code of less than 400. Additionally, redirects are also considered successful transactions.