How to Use Siege to Load Test Your WordPress Website

Loading testing is an essential part of web development which is usually forgotten or neglected until a website is under intense load. It is useful for testing the performance of your site, and the infrastructure that it runs on.

There’s nothing more terrible than having a page on your site posted on a popular site like Facebook or Reddit and watching your site crumble under the load. Siege can stimulate multiple requests to your site, it’s able to measure the response times across the various requests.

Typically, once you are running the siege process, you can visit the website you are testing to experience how the website will perform when users are browsing it. Siege allows you to replicate how your website will perform when a certain number of simultaneous visitors come to your website.

In this post, we will be covering one of the tools that we use when working with our clients. We will go over the installation of Siege on OS X and Linux, and run a basic load test with Siege.

Siege can be defined as an HTTP load testing and benchmarking utility. According to the official definition, it was designed specifically to let web developers measure their code under duress, to see how it will stand up to load on the internet.

Siege supports basic authentication, cookies, HTTP, HTTPS and FTP protocols. It lets its user hit a server with a configurable number of simulated clients. Those clients place the server “under siege.”

Siege was developed on Linux and has been ported to other platforms including AIX, BSD, HP-UX and Solaris. It successfully compiles on most System V UNIX variants and on most newer BSD systems.

Because Siege relies on POSIX.1b features not supported by Microsoft, it will not run on Windows.You can, however, use Siege to test a Windows web server if that’s what you are using to run a WordPress website.

Installing Siege

If you are running the latest version of Centos with epel repo enabled, you can use the official package manager called yum to install Siege by using the command below:

sudo yum install siege

In the same light, you can also use the official package manager on Ubuntu or Debian to install Siege by using the command below:

sudo apt-get install siege

Additionally, if you are running a Mac OX computer, you can use brew to install Siege. Brew, is one of the popular package managers on Apple computers. You can install Siege using the command below:

brew install siege

Finally, we want to see how we can install Siege from source, this means we will be downloading the source code and compiling it locally, this works best for you if for some reason you cannot use the package manager on your computer. Follow the instructions below to download and compile siege.

cd /opt

At this point, we will extract the archive and start to compile Siege from source using the list of command below:

tar -xvf siege-latest.tar.gz

Now, change to the archive directory

cd siege-3.1.0

Now, we will go ahead and configure and build the package using the list of command below:

make install

If you are interested in the source code of Siege, you can visit the Github project page for more information.

At this point, you should have successfully installed Siege on your system. To confirm that you have successfully installed it, you can run the following command in the terminal, this work on all variants of Linux and Mac OSX as well. Type the command below to make sure you have Siege installed before you proceed.

siege -V

//below is the output of this command
SIEGE 3.1.0

Start Load Testing With Siege

We are going to start testing with Siege. To run Siege with the default settings, input the following command, replacing with your domain name or IP address:


Once this command is successfully run you should see an output similar to the output below, Your results might vary depending on the speed of your internet connection or the capacity of the infrstrutre you are running your website on.

** SIEGE 3.10
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
Transactions:		        2913 hits
Availability:		      100.00 %
Elapsed time:		       40.51 secs
Data transferred:	        0.41 MB
Response time:		        0.00 secs
Transaction rate:	       40.95 trans/sec
Throughput:		        0.01 MB/sec
Concurrency:		        0.04
Successful transactions:        2313
Failed transactions:	           0
Longest transaction:	        0.01
Shortest transaction:	        0.00

FILE: /var/log/siege.log
You can disable this annoying message by editing
the .siegerc file in your home directory; change
the directive 'show-logfile' to false.

Are you can see from the response above there is a siegerc file in your home directory which allows you to change the default configuration that Siege runs with. By default, it uses 25 concurrent users. You can increase this for a more intense test.

Also, from the output above you would notice how the server performed. Firstly there was 100% uptime, meaning, the server didn’t go down or was not overwhelmed by the number of requests that it received. What that means is that your website can successfully handle 25 concurrent users without any performance degradation.

Another important number that you also want to look at it the longest and shortest transaction times for the requests. This tells you how long the server took to process the request.

As you have noticed from the example about testing only one URL is not entirely realistic because multiple users might visit different pages on your website. To simulate this behavior more accurately, you have to supply a list of URLs to siege to test with.

For most WordPress websites and themes we test, we usually select a combination of URLs such as the homepage, a category page, an author page, a tag page, a search and a single post page. This provides us a list of URLs that capture most parts of the website or theme functionality.

To set this up you only need to specify the list of URL in a text file like below:

# URLS file for siege
# --
# Format the url entries in any of the following formats:
# http://www/index.html
# www/index.html
# Use the POST directive for pages that require it:
# POST ha=1&ho=2
#      or POST content from a file:
# POST < /home/jeff/haha
# POST < ./haha
# You may also set and reference variables inside this file,
# for more information, man urls_txt
# -------------------------------------------------------

Once you have selected the URLs you can simply run the command below to start running the load test:

siege -f your/file/path.txt

As a final step, we want to list out the top options we use with Seige when running a load test:

  • -c [num]: Set the number of concurrent users. This is constrained by how much RAM you have on your computer. Most web servers have less than a couple hundred users trying to access their website at the same time, so setting this to more than a few hundred is often not needed.

  • -t [num]: Set a time limit for which Siege runs. Siege can run with the modifiers s for seconds, m for minutes, or h for hours. There should be no space between the number and the modifier (-t10s not -t10 s).

  • -d [num]: Set the delay for each Siege user. Each user is then delayed for a random amount of seconds in between 1 and the set number. The default value is 3.

  • -i: Used in conjunction with a URLs file, this causes each user to randomly hit one of the URLs, with no predetermined pattern. Similar to real life (the ‘i’ stands for “internet”), where you will not know where site visitors go, not all pages may be hit.

  • -v: Verbose output. This outputs the results Siege gets in real time before printing the final results.

  • -f [file]: Run Siege with a file containing a list of URLs that is not the default urls.txt file.
  • -g [url]: Pull down the HTTP headers.
  • -l: Generates a log file.
  • -m "[message]": Include a message in the log file.
  • -C: Outputs Siege’s current configuration profile.
  • -V: Outputs Siege’s version information.
  • -h: Outputs help information.

We hope you enjoyed reading this post. Let us know what you think in the comments below. Feel free to share how you perform load tests on your websites as well.