Business owners often times don’t recognize the importance of website testing. To be fair, website testing does get a decent share of attention. Yet, its use as an ongoing website support practice is often overlooked. Website testing should be an essential component of your business strategy.

One useful tool you may consider for this purpose is JMeter. So get comfortable, and let’s talk about how you can use JMeter to conduct stress testing for your website.

An intro to website stress testing

Website stress testing allows you to analyze and quickly detect website performance issues. Moreover, it will let you know in advance when you need to replace your servers.

Website stress testing using JMeter relies on 4 criteria:

1. Processor

The processor is the most important criterion, since it provides the main computations. You can analyze the processor data without any fancy technical background. The only thing you need to know is where to look.

You’ll first need to download and install a convenient little tool called TerminAll. Afterward, enter the tool and type top. You’ll see the following image:

You can ignore most of the gibberish here except these three measures:

  1. Percentage of current processor usage (CPU). The higher the percentage, the higher the load or even overload.
  2. Percentage of free CPU. The more free CPU, the better the potential.
  3. Load average. The first number shows your processor’s load average for one minute. The second for five minutes, and the third for 15 minutes.

The “load average” number is the hardest to interpret. Depending on the number of load streams, you should interpret the “load average” differently. Here’s an example of a two-stream processor with a load average of 2.00, 0.40, and 3.35:

  • 2.00 means the processor is loading 200 percent during one minute.
  • 0.40 means the processor hasn’t been using 160 percent of its load potential during the last five minutes. In other words, no process has been in a queue during the last five minutes.
  • 3.35 means the processor has been overloaded 135 percent on average during the last 15 minutes. It means 1.35 processes have been in a queue during the last 15 minutes.

2. Memory

This criterion is often referred to as RAM (random-access memory). You can find this valuable piece of data by entering cat/proc/meminfo into your TerminAll.

Here, we’re looking for the following:

  1. Free memory. You always want it to be around 30–50 percent for all your processes to function smoothly.
  2. Swap memory. You definitely don’t want your memory to fall into swap, since you need it at all times.

3. Hard disk

You need to assess your hard drive capacity to know when to buy more servers. To do so, type df-h.

In short, you need at least 10 percent of free space on your hard drive. Yet, keep in mind that the hard drive can have an unusual load while processing files and databases.

4. Network

The high network traffic is the least important criterion to follow. Still, peak measures show the need to scale your network. For example, an average traffic of 95 MB on a 100 MB interface indicates the need to swap out your server soon. To see the network traffic, type cbm.

JMeter overview

Now that you know all the measures for website stress testing using JMeter, let’s jump to the tool itself. You can use JMeter for load and stress testing of many services like web applications. Moreover, JMeter is totally free and cross-platform.

To begin working with JMeter, follow these two easy steps:

  1. Install JRE or JDK. You’ll need one of these because JMeter is written using Java.
  2. Install and start up JMeter.

Additionally, you might want to install JMeter Plugins Manager to connect it to different tools. First, download the “JAR plug-in manager” file and drag it into the “lib/ext JMeter” catalog. Then, open JMeter and go to “Options” to find “Plugins Manager.”

To break things down a little further, here’s a glossary of most of the JMeter terms you’ll need to know.

  • Number of Threads (Users) is the number of similar virtual users (aka streams).
  • Thread Group is a scenario processing a certain amount of virtual users (aka streams).
  • Ramp-up Period is a period of time for processing all threads.
  • Loop Count is the number of scenario reiterations.
  • Scheduler is an option to schedule your test to start at a certain period.
  • Delay Thread Creation until Needed is an option to save computer resources. The option doesn’t make a drastic difference in the amount of saved resources. Still, it can be quite useful, as you can see in the chart below.

The way your JMeter works is simple. First, you create different thread groups mirroring behaviors of your website users. Next, you set up the necessary thread number, loop count, and ramp-up period for those thread groups. You should do it to scale those behaviors. Finally, you analyze your JMeter and TerminAll data, and you’re good to go.

An example of website stress testing using JMeter

Here’s a very simple stress test comparing 2 PHP frameworks, Laravel and Symfony. I am using a server with a 2GB RAM and a 1 GB SWAP. Also, it has a 2 core CPU as well as a 15GB HDD.

Step 1. Create the Test Plan

First, I create a Test Plan and run it six times for two minutes each time to gather reliable “load average” data. The test includes the following Thread Groups:

Thread Group 1

  1. Main Page
  2. Authorization
  3. Creating a Blog Post
  4. Main Page

Thread Group 2

  1. Main Page
  2. Blog Post Page
  3. Main Page
  4. Blog Post Page

Thread Group 3

  1. Main Page
  2. Authorization
  3. Blog Post Page
  4. Main Page
  5. Blog Post Page

Step 2. Set up Threads

Next, I set up the proper number of threads, the ramp-up period, and the loop count for each separate thread.

I set ramp-up period and loop count to one, to simplify things. But, I’m also creating a variation in the number of threads by setting them to 30, 60, 90, 105, 110, 120, 135. The logic here is to measure how Laravel and Symfony perform under the different user loads. Unfortunately, I have to set the number of threads for each of six tests one by one.

Step 3. Analyze data

Most of the quality data JMeter displays is in the “Summary Report”:

  1. #Samples — the total amount of requests to our server.
  2. Average, Min, Max — the time it takes to process one request. The numbers are shown in milliseconds.
  3. Error % — the percentage of mistakes with errors.
  4. Throughput — the number of processed requests in a given period of time.

Some of it is in the “View Results Tree”. Below, you can see the log for each website/server request. Moreover, you can analyze those requests that went wrong or overloaded your server. The data is useful but not complete without the help of TerminAll analytics.

Results

I’ve run the test six times with different numbers of threads. The data show the Laravel version of the website is slightly better than the Symfony version.

I’ve illustrated these three measures in a graph comparing Laravel and Symfony. You can see that Laravel is overloaded by 120 users and can’t compete with Symfony. The Symfony website also has a faster average response time than Laravel. But, Laravel has a slight edge when it comes to the amount of requests it can process. Yet, it is still overwhelmed by 120 simultaneous users.

And this sums it up! Thanks for reading, and I hope you find this article useful.

My company KeenEthics has solid experience with software support and stress testing. In case you need the following services, Contact Us.

How to Choose Your Optimal Development Methodology
We have consulted KeenEthics project managers as for which methodologies they use while working on different projects. Together with them, we compiled this ultimate project management guide... keenethics.com

Written by Romanyuk Oleg, Marketing Manager @ KeenEthics.

Originally published at enlightened-digital.com on June 27, 2018.