Many business owners who have jumped 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 concepts like “website testing.” To be fair, website testing does have a decent share of visibility in the tech world. However, its use as an ongoing website support system is often overlooked.. Website testing should be an essential component of your overall 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.
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 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.
You’ll first need to download and install a convenient little tool called TerminAll. Afterward, enter the tool and type in the “top” command. You’ll see the following image:
You can ignore most of the gibberish here except these three measures:
- Percentage of current processor usage (CPU). The higher the percentage, the higher the load or even overload.
- Percentage of free CPU. The more free CPU, the better the potential.
- 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, the “load average” number should be interpreted 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, meaning 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). This valuable piece of data can be found by typing the “cat /proc/meminfo” command into your TerminAll.
Here, we’re looking for the following:
- Free memory. You always want it to be around 30-50 percent for all your processes to function smoothly.
- 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 in order to know when to buy more servers. In order to do so, type in the “df-h” command.
In short, you need at least 10 percent of free space on your hard drive. However, keep in mind that the hard drive can temporarily experience unusual load while processing files and databases.
4. Network
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 interface indicates the need to swap out your server soon. To see the network traffic, type in “cbm.”
JMeter Overview
Now that you know all the measures for website stress testing using JMeter, let’s jump to the tool itself. JMeter can be used for load and stress testing a number of services, particularly web applications. Moreover, JMeter is totally free and cross-platform.
In order to begin working with JMeter, follow these two easy steps:
- Install JRE or JDK. You’ll need one of these because JMeter is written using Java.
- Install and start up JMeter.
Additionally, you might want to install JMeter Plugins Manager to connect it to different other tools. First, download the “JAR plug-in manager” file and drag it into the “lib/ext JMeter” catalog. Then, just open JMeter and go to “Options” to find “Plugins Manager.”
To break things down a little further, here’s a glossary of 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 but can still be quite useful, as be seen in the chart below.
The way you JMeter works is simple. You create different thread groups resembling certain theoretical behaviors of potential website users, aiming to make the users behave as realistically as possible. Afterward, you create the necessary thread number, loop count and ramp-up period for those thread groups in order to scale those behaviors. Finally, you analyze your JMeter and TerminAll data, and you’re good to go.
Website Stress Testing Using JMeter (Example)
Here’s a very simple stress test comparing 2 PHP frameworks,Laravel and Symfony, 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.
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
- Main Page
- Authorization
- Creating a Blog Post
- Main Page
- Thread Group 2
- Main Page
- Blog Post Page
- Main Page
- Blog Post Page
- Thread Group 3
- Main Page
- Authorization
- Blog Post Page
- Main Page
- 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, in order to simplify things. However, I’m also creating 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 separately.
Step 3. Analyze data
Most of the quality data JMeter displays is in the “Summary Report:”
- #Samples – the total amount of requests to our server.
- Average, Min, Max – the time it takes to process one request. The numbers are shown in milliseconds.
- Error % – the percentage of mistakes with errors.
- 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 and/or overloaded your server. The data is useful but not complete without the help of TerminAll analytics.
Results
Having run the test six times with different numbers of threads, I’ve put together an interesting picture. According to the data I’ve gathered, the Laravel version of the website appears to be slightly better than the Symfony version.
I’ve illustrated these three measures in a graph comparing Laravel and Symfony. You can see 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. However, it is still overwhelmed by 120 simultaneous users.
And that just about sums it up! Thanks for reading, and I hope you find this article useful.
For more articles related to software development testing, you can read a blog post from DevCom titled AI Bots Are Coming for Your Testing Jobs.