How to Stress Test Your WordPress Site for Traffic Surges

How to Stress Test Your WordPress Site for Traffic Surges

It’s important to know just how well your WordPress website can handle large amounts of traffic in the event you get a sudden traffic spike. With Tsung, you can stress test your site for free, see your server’s limits first-hand, and use the data to create a plan to scale your site.

Tsung (formerly IDX-Tsunami) is an open source distributed load testing tool that works on most servers and can stress test many platforms, including HTTP and MySQL. You can run it via SSH and it simulates a sudden amount of high traffic being sent to your site from a single machine, although, you can also create clusters.

Tsung is developed in Erlang and even though it is used to stress test your site, the actual processes it sends are lightweight so you can see how much your site can handle without breaking it or crashing Tsung.

Unfortunately, the official documentation for Tsung isn’t completely up-to-date, so in this post I’ll show you how to install Tsung using Wget. I’ll also walk you through how to generate reports for each test you run so you can analyze the data that Tsung generates after a successful load test.

What is Tsung?

The development of a distributed load stress test tool began in 2001 by Nicolas Niclausse, but it was meant to be used internally by IDEALX (now OpenTrust) and it wasn’t until several months later that it evolved into an open source project.

Tsung simulates real users on a server and can stress test many platforms, including HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and Jabber / XMPP servers.

It can be used to test your site and send high load tests from 12,000 to 10 million simultaneous users.

A simple graph drawing.
Graph reports can be generated from Tsung.

In fact, these numbers weren’t just pulled out of nowhere – it has been successfully used this way in the past.

Tsung is now an industrial-strength tool that has been used by many high profile companies and institutions including Oracle, for its Moodle software platform, and the French Finance Ministry (Direction Générale des Impôts or DGI).

You can run the tool through SSH on clients such as Terminal for Mac OS X or PuTTY for Windows. Fire up your favorite SSH client to get started right away.

Server Requirements

There are a few requirements needed in order to run Tsung so it’s important that they’re installed and taken care of first. Tsung can be installed on Linux, Solaris, BSD, Win32 and Mac OS X servers and you need to have root access to your server in order to install and run Tsung.

You can use sudo to run commands as the root user and you can check out the official documentation for these options to reference their installation:

You also need to have the latest version of PHP installed on your server. You can check out the Getting Started and the Installation and Configuration guides for reference on how to install them.

After logging into the root via SSH, you can check which version of PHP you’re running by entering in php -v.

Installing Tsung and its Dependencies

Now you’re ready to start installing the programs that are necessary for Tsung to run. Many of them are already packaged into Tsung, but there are a few others you need to make sure you have installed as well.

While you can install Tsung and its dependencies in many ways depending on your server, the installation process is covered here using Wget. If you don’t already have Wget installed on your server, you can check out the Introduction to GNU Wget guide.

Start by installing Erlang, a programming language. You can grab a link to the latest version on Erlang’s official download page and you can install it with Wget:

Keep in mind that you should make sure you’re installing the latest version of Erlang. Replace the URL in this example with the URL of the most up to date version from Erlang’s download page.

Next, unpack the compressed file, but be sure you replace otp_src_18.2.1.tar.gz with the name of the file you called with wget. It may not be the same if there have been updates since the time this article was written.

Go to the directory you just created by entering this command, but don’t forget to replace otp_src_18.2.1 if needed:

Now it’s time to configure, build and install Erlang now that it’s uncompressed and on your server. You can use the following command and you don’t have to change anything:

This last step may take a few minutes so feel free to grab some water or a cup of coffee in the meantime. Once that’s complete, you can install Perl5 and Gnuplot in the same way if you don’t already have them installed. These are used to produce the text and image graphs and data after you run a stress test.

You can also find the download file of Gnuplot on Sourceforge, but I found the installation was a bit trickier, though, only because I wasn’t paying close enough attention.

When using wget to add the compressed file from SourceForge onto your server, I eventually noticed that I couldn’t uncompress the file using tar xvzf gnuplot-5.0.3 because that wasn’t what the compressed file was called. Instead, I needed to unpack it with this command:

I was only then able to go to the directory with the more obvious name:

Afterward, I could finish by configuring and installing Gnuplot as you normally would for most other programs.

It’s a good idea to do what I didn’t do at first, which is pay attention to details such as file names since it could be the reason why you get mysterious errors that, in truth, have easy fixes.

The last step is to install Tsung and you can get the URL of the latest version from Tsung’s download page. Once you have the link, you can use wget to unpack and install it on your server just as described above for Erlang.

Running a Stress Test

After you have successfully installed Tsung and its dependencies, you’re ready to start your first stress test. This usually requires creating an XML file with the specifics on the type of test you want to run, but Tsung does come pre-loaded with sample files that are great to use.

You can find these files by going into the secondary tsung directory, then to the examples folder by entering this command into your SSH client:

Now you should be in the /tsung/examples/ directory from the root of your server, but you won’t be able to see any files listed until you enter ls to list all the files in this directory. Once they’re all listed, you can decide which script you want to run.

Not all of the example files listed are going to be relevant to stress testing a WordPress site so be careful not to pick just any one of them.

If you’re not exactly sure which one to try out, you can start with the http_simple.xml file. This is a great basic test to run for your WordPress site.

Sample XML files are listed on the PuTTY client.
The list of examples files have been generated.

Once you decided on an XML file, you can run your stress test. Just be sure your SSH client is pointed to the directory where your file is located before entering the command to start the test.

I decided to use the basic http_simple.xml so this is the command I would use to begin the test, though you could replace it with the file you want to use:

A message should display saying “Starting Tsung,” then another line should follow with a message that looks similar to this one:

Log directory is: /root/.tsung/log/20160311-1644

This is where that data for the results of your stress test are stored. Make a note of it since you need it to generate and view a report. The log file itself is written to show the date and time of the stress test so it’s easier to keep track of all of them. It starts with the numeric year, the month and the day, followed by a hyphen, then the time in the 24-hour format.

When your stress test is complete, you should know because you’re able to type in another command.

Generating a Report

Once your stress test has been completed, you can view a report of how it went, but first you need to generate one. You also can choose to generate one as the test is being completed so you can monitor the progress if you want.

First, go back to the root by typing in cd ~, then go to the directory with your log. In keeping with the example above, here’s the kind of command you would enter to get there:

If you’re not sure what the direct path is to your root, you can replace /root in the above example with a ~ punctuation to get the same result.

To generate the report, type in the following command:

Your reports should have been created and you can view them in the path you noted earlier. Once in that directory, you can enter the ls command to view the available report files.

You can view them using an SSH browser such as links or other server-based browsers with graphics enabled. Links works on most servers and you can learn how to download and install links by checking out the Twibright Lab’s Links Download guide.

Once it’s configured and installed and the graphics have been enabled, you can go to the directory where your logs are stored as shown above. Once you’re there, run the links command for the report page:

The page should display similar to a regular browser page and you should be able to view your report.

An HTML output of the stress test data.
An example of a report that’s generated by Tsung.

The report is divided into sections to show you information on the simulated traffic:

  • request – Response time of each request
  • page – A group of requests and the response time of each
  • connect – Duration of the established connection
  • reconnect – Number of times a reconnection occurred
  • size_rcv – Size of responses in bytes
  • size_sent – Size of requests in bytes
  • session – Duration of a simulated user’s session
  • users – Number of simultaneous simulated users that started a session, but didn’t finish
  • connected – Number of users with an opened connection
  • mean response time –Average response time that’s calculated every 10 seconds and then resets

It may be important to note that since the mean response time is reset every 10 seconds, there are likely to be different averages through different points during the test. This is why a lowest, highest and overall mean response time is calculated so you can see what your high and low points were along with how you did overall.

One of the most important sections to look at when running a stress test on your site is the HTTP Return Code section. This is only something you should watch out for if you’re running an HTTP test.

In such cases, if the code section shows anything higher than in the 200-300 range and reaches into the 400-500 range, your server needs some big changes or there are bugs.

You may have had too many simultaneous requests in the test, which means your server isn’t quite scaling or there are bugs on your site, server or in the XML file you used for the test. Overall, this is a great indicator of a successful – or not so successful – test of your site and server.

You could also create your own XML files to fully customize the test if you would like and the details on how to do this are in the Tsung official documentation.

Finishing the Stress Test

Stress testing your site and server is a great way to learn whether or not improvements can be made and if your site is set up well for scalability. With Tsung, you can not only run these kinds of tests for free, but detailed reports are also generated so you can see how your server handles a sudden traffic spike.

You can also run the tsung -h command to get a useful lists of options available to run a tsung stress test. If you need more help and need to ask a question, there are many companies pitching in to offer support and you can find a complete list on the support page on the Tsung website.

You can also check out the bug tracker on GitHub to submit an issue if you find one, although, it may be important to note that you may not get proper support if you have an issue with using Tsung, rather than if you were reporting a bug.

Have you ever used Tsung or tried stress testing your server? Do you know of other tools for stress testing that you prefer over Tsung? Share your experiences in the comments below.

Jenni McKinnon

Jenni McKinnon Jenni has spent over 15 years developing websites and almost as long for WordPress as a copywriter, copy editor, web developer, and course instructor. A self-described WordPress nerd, she enjoys watching The Simpsons and names her test sites after references from the show.