Many business owners who are jumping on the digital transformation bandwagon are swimming in a sea of tech buzzwords. These may include ‘big’ words like artificial intelligence and virtual reality. Therefore, they oftentimes fail to recognize the importance of simple tech notions like ‘website testing’. To be fair, the website testing does have a decent share of publicity in the tech world. However, it’s overlooked in the sense of a continuous website support. Just to say ‘you should do it’ is an understatement. Website testing should be a part of your overall business strategy. Period. One useful tool you may consider for this purpose is JMeter. So, here I come to the topic of the article ‘how you should perform website stress testing using JMeter’.

If you’re not a tech person you can definitely send this article to your sysadmin. This blog post will most certainly help your effort with continuous website support. Otherwise, get comfortable, and let’s talk about website stress testing using JMeter.

Website stress testing using JMeter allows you to analyze and quickly detect issues with website performance. Moreover, it will let you know in advance when you need to buy new servers.

Website stress testing using JMeter relies on 4 criteria:

criteria for website stress testing

1. Processor

The processor is the most important testing 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.

Download and install a nice little tool titled TerminAll. Afterward, enter the tool and type in the ‘top’ command. You’ll see the following picture:

processor data

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

  1. Percentage of current processor usage (CPU). The higher the percentage – the higher 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 1 minute, the second – for 5 minutes, and the third – for 15 minutes.

The ‘load average’ number is the hardest to interpret. Depending on the number of load streams, the ‘load average’ number should be interpreted differently. Here’s an example of a 2 stream processor with a load average of 2.00, 0.40, 3.35:

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

I told you, it’s not a rocket science!

2. Memory

Moving on. We can call this criteria RAM, Random-access memory, or simply the memory. This valuable piece of data can be found by typing ‘cat /proc/meminfo’ command into your TerminAll.

memory data

Again, you should be interested only in a few measures:

  1. Free memory. You always want it to be around 30-50% 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. That’s all!

3. Hard disk

Next. You need to assess your hard drive capacity in order to know when to buy more servers.

In order to do so, type in ‘df-h’ command

hard drive data

In short, you need at least 10% of free space on your hard drive. However, keep in mind the hard drive can temporarily experience unusual load while processing files and databases.

4. Network

Lastly, the high network traffic is the least important criterion to follow. Nevertheless, peak measures do indicate the need to scale your network in the near future. For example, an average traffic of 95 MB on a 100 MB-large interface most certainly indicates the need to change your server soon.

In order to see the network traffic, type in ‘cbm’.

network data

JMeter Overview

Now, we know all the measures for website stress testing using JMeter. Let’s jump to the tool itself. JMeter is a tool for load and stress testing of a whole number of services focusing on web applications. Moreover, JMeter is totally free and cross-platform.

In order to start your work with JMeter, you should follow 2 simple steps:

  1. Install JRE or JDK. You most definitely need one of these because JMeter is written using Java;
  2. Install and start JMeter. Then, behold this wonderful tool!

website stress test using jmeter

Additionally, you might want to add JMeter Plugins Manager to connect it to different other tools. Firstly, you have to download the ‘JAR plug-in manager’ file and put it into the ‘lib/ext JMeter’ catalog. Secondly, open your JMeter and go to ‘Options’ to find ‘Plugins Manager’. As simple as always!

jmeter plugin

This is a long article, and I’m glad you made it this far. I most certainly don’t want to make your life difficult, so here’s the list of almost all of the JMeter terms in one pace. You’re welcome!

The list of terms to remember:

  • Number of Threads (Users) is a certain 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 for processing all threads;
  • Loop Count is a number of scenario reiterations;
  • Scheduler is an option scheduling your test to start at a certain period;
  • Delay Thread Creation until Needed is an option saving computer resources. The option doesn’t save the resources dramatically but can still be quite useful as can be seen in the chart below.

delay thread chart

The way you make JMeter work is plain and simple. You create different thread groups resembling certain theoretical behaviors of potential website users. You make the users behave as realistically as possible. Afterward, you create the necessary thread number, loop count and ramp-up period for these thread groups in order to scale these behaviors. Lastly, you analyze your JMeter and TerminAll data. Job well done!

Website Stress Testing Using JMeter (Example)

Finally, let’s make some JMeter stress testing. You can follow along with your own testing using this example as a template. So, I will show you a very simple stress test comparing 2 PHP frameworks, namely Laravel vs Symfony. We’re using a server with a 2GB RAM and a 1 GB SWAP. In addition, it has a 2 core CPU as well as a 15GB HDD.

laravel vs symfony

Step 1. Create the Test Plan

I’m creating a Test Plan and running it for 6 times for 2 minutes each to get reliable ‘load average’ data. The test includes the following Thread Groups:

Test Plan

  • 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

I’m setting up a proper number of threads, ramp-up period and loop count for every thread separately. Thusly, I’m bringing some reality to the test.

Thread Group

I’m setting ramp-up period and loop count to 1, in order to make it more simple. However, I’m also setting the number of threads to different amounts, specifically 30, 60, 90, 105, 110, 120, 135. The logic here is to measure how Laravel and Symfony will perform under the different user loads. Unfortunately, I have to set the number of threads for each of 6 tests separately.

Step 3. Analyze data

JMeter shows some quality data. Most of it is in the ‘Summery 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.

summary report1

summary report2

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

view results

Results

It’s time to reap the fruit of the job well done! Having run the test 6 times with different numbers of threads, I get an interesting picture. Laravel version of the website is slightly better than the Symfony version. Don’t get me wrong, I don’t claim Laravel is better than Symfony. I’m just reporting the data I see below.

results table

Results table

I have turned these 3 measures into a convenient table comparing Laravel and Symfony. Firstly, you can see Laravel is overloaded by 120 users and can’t keep up with Symfony.

Load average results

Secondly, Laravel can process a little more requests than Symfony. However, it is overwhelmed by 120 simultaneous users.Throgout

Finally, the Symfony website has a faster average response time than Laravel.

Average response comparison

So, that sums up our dive into website stress testing using JMeter! Thanks for reading on, and I hope you find this article useful.

Keep in mind. DevCom has solid experience with software support and stress testing. In case you need the following services, Contact Us.

For more articles related to software development testing feel free to read AI Bots Are Coming for Your Testing Jobs.

Written by Romanyuk Oleg, Marketing Manager @ DevCom.

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