Website Performance Load Testing Using JMeter.!
What is Jmeter?
JMeter is a software that can perform load test web services, functional test, regression test, etc., on different technologies & protocols. Existing functionality of JMeter and its provided UI allow us to simulate a load of 5 concurrent threads hitting the server with 10 and 5 ms delays.
The original developer of Jmeter was from the Apache Software Foundation named Stefano Mazzocchi. He wrote it primarily to test the performance of Apache JServ and later redesigned JMeter to enhance the GUI and to add functional testing capabilities.
Along with a graphical interface ‘Jmeter’ as a Java desktop application uses the Swing graphical API. Moreover, it can run on any workstation / environment that accepts a Java virtual machine, e.g. Windows, Linux, Mac, etc.
Here, in this article we will learn the steps to know about a website performance load testing using JMeter.
Before going into the details of JMeter, we should need to understand a few jargons associated with the testing of any application, i.e.
- Performance Test − Under a given configuration of infrastructure, this test sets the best possible performance expectation. Before the application goes into production, if any changes need to be made then it may be highlighted early in the testing process.
- Load Test − This test is basically designed to be used for testing the system under top load.
- Stress Test − This test is attempted to break the system by overwhelming its resources.
JMeter supports the following protocols :
- Web − HTTP, HTTPS sites ‘web 1.0’ web 2.0 (i.e. ajax, flex and flex-ws-amf)
- Web Services − SOAP / XML-RPC
- Database via JDBC drivers
- Directory − LDAP
- Messaging Oriented service via JMS
- Service − POP3, IMAP, SMTP
- FTP Service
JMeter Characteristics :
- Freely available open source software.
- Simple and intuitive GUI.
- Load and performance test can be conducted for many different server types, i.e. Web – HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail – POP3, etc.
- A platform-independent tool. It can be invoked by clicking JMeter shell script On Linux/Unix. and on Windows, it can be invoked by starting the jmeter.bat file.
- Full Swing and lightweight component support.
- Jmeter allows to generate a test plan using a text editor, as it stores test plans in XML format.
- Its full multi-threading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups.
- Highly extensible.
- Allows to perform automated and functional testing of the applications.
Jmeter sends requests to a target server by simulates a group of users and finally returns with the statistics that exhibit the functionality/performance of the target server/application via graphs, tables etc.
As ‘JMeter’ is a Java framework, so the very first we need to have JDK installed in our machine.
|JDK||1.6 or above.|
|Memory||No minimum requirement.|
|Disk Space||No minimum requirement.|
|Operating System||No minimum requirement.|
JMeter Distributed Testing Steps :
Here you will learn, how to use multiple systems to perform stress testing. There are a some important things to check, before start.
- Turn off the firewalls on the systems.
- All the clients must be on the same subnet.
- Also, the server must be in the same subnet, if 192.x.x.x or 10.x.x.x ip addresses are used. There shouldn’t be any problem, if the server doesn’t use 192 or 10 ip address.
- Check and ensure JMeter can access the server.
- Different or Mixing of versions may not work correctly. So, make sure to use the same version of JMeter on all the systems.
You can start setup remote testing, once you’ve ensured the systems are ready.
JMeter works as one master controller and initiates the test on multiple slave systems, as shown in the following Diagram :
Also, It would be wise to know the following terms, before we dive into the step-by-step instructions :
Master– the system runs Jmeter GUI and controls the test.
Slave– the system running jmeter-server, which takes commands from the GUI and send requests to
the target system(s)
Target– the webserver we plan to stress test
Steps Involved :
1. Go to jmeter/bin directory, on the slave systems, and execute jmeter-server.bat (jmeter-server on unix). See on windows, a dos window should appear with “jre\[version]\bin\rmiregistry.exe”.
If this doesn’t happen, either there may be multiple JRE installed on the system or the environment settings are not right.
Note: There would be the jre version installed on the system.
2. In a text editor open jmeter-server.bat
3. Go to line 44 and find “:setCP”
4. Edit “START rmiregistry” to the full path. e.g. “START C:\\jre\bin\rmiregistry”
5. open windows explorer and go to jmeter/bin directory
6. Open jmeter.properties in a text editor, on master system acting as the console.
7. Edit the line “remote_hosts=127.0.0.1”
8. Add IP address. e.g. if jmeter server running on 192.168.0.10, 11, 12, 13, and 14, then the entry would like like this:
9. Start jmeter.
10. Open the test plan to use.
How to Start the Test ?
You can double check working of the slave systems to open jmeter.log in notepad. You should see the following in the log :
Jmeter.engine.RemoteJMeterEngineImpl: Starting backing engine
Now, you are ready to start load testing.
If this message is not seen, then it means jmeter-server did not start correctly.
There are two ways to initiate the test: a single system and all systems.
Starting a Single client :
On the top panel, Enter Run
Select Remote start
Select the IP address
Starting All Clients
- At the top of panel click Run
- Select Remote Start All
Distributed testing may comes with some basic limitations, as shown in the list below :
1. RMI cannot communicate across sub-nets without a proxy; therefore neither can jMeter without a proxy.
2. Since JMeter sends all the test results to the controlling console, it is easy to saturate the network IO. It is a good idea to use the simple data writer to save the results and view the file later with one of the graph listeners.
3. Unless the server is a large multi processor system, in most cases 1-2 clients is sufficient to overwhelm the server.
4. A single JMeter client running on a 2-3Ghz CPU (recent cpu) can handle 300-600 threads depending on the type of test. (The exception is the webservices). XML processing is CPU intensive and will rapidly consume all the CPU cycles. As a general rule, the performance of XML centric applications will perform 4-10 slower than applications using binary protocols.
Sometimes, the Symantec Anti Virus and Firewall may still be blocking RMI traffic. So, in some cases Symantec firewall needs to be stopped from windows services as mentioned below:
- Open control panel
- Open administrative tools
- Double click services
- Go to down to symantec anti virus, right click and select stop Windows firewall
- Open network connections
- Select the network connection
- Right click and select properties
- Select advanced tab
- Uncheck internet connection firewall
How JMeter can be used for Performance Testing ?
Performance testing can be used to analyze overall server performance under heavy load. It is crucial to determine that the web application under test will satisfy high load requirements.
Performance Testing Comprises:
Load Testing: Concurrently simulates multiple users access to the web services for modeling the expected usage.
- Stress Testing: As per load capacity, every web server start responding slowly and produce errors, when the load goes beyond their maximum limit. Stress Testing is performed to find the maximum load the web server can handle.
How JMeter simulates the heavy load is clearly shown below in figure :
JMeter offers following benefits :
- Discover maximum number of concurrent users that your website can handle
- Provides various graphical analyses of performance reports.
Creating JMeter Performance Test Plan
Here, as an example we are doing a performance analysis of Google.com for 1000 users.
First, we need to determine-
- Normal Load: Average number of users visiting a website
- Heavy Load: The maximum number of users visiting a website
- What is final target to perform this test?
Roadmap of this practical example stepwise described below :
A) Add Thread Group
Select Test Plan
- Add Thread Group (Add → Threads (Users) → Thread Group)
In the control panel of Thread Group, enter Thread Properties as shown :
Number of Threads (users connects to target website): 100
Loop Count (time to execute testing): 10
- Ramp-Up Period: 100
The Loop Counts and the Thread Count are different.
‘Ramp-Up Period’ guides JMeter how long to delay before starting next user. e.g. the delay between starting users would be 1 second (100 users /100 seconds), if we have 100 users and a 100 second Ramp-Up period.
B) Add Elements
Here, we determine JMeter elements in this test.
The elements are ;
- HTTP Request Default
Right-click on Thread Group and select Add → Config Element → HTTP Request Defaults.
Enter the Website name under test i.e. http://www.google.com, in the HTTP Request Defaults control panel.
Right-click on Thread Group and select: Add → Sampler → HTTP Request.
The Path field in HTTP Request Control Panel, indicates URL request of user want to send to Google server.
e.g. JMeter will create the URL request http://www.google.com/calendar to Google server, if user enter “calendar” in Path field.
JMeter will create the URL request http://www.google.com to Google server, with a blank Path field.
C) Add Graph Results
The test result can be seen in Graphic format with Jmeter.
Right click Test Plan, Add → Listener → Graph Results
D) Run Test to Get the Test Result
On Toolbar to start the testing process, press Run (Ctrl + R).
The test result will be displayed on Graph at the real time.
We can see a graph of a test plan below link, where we simulated 100 users who accessed on website www.google.com. :
The following statistics are represented in colors, at the bottom of the picture :
- Black: The current total number of samples sent.
- Blue: The current average of all samples sent.
- Red: The current standard deviation.
- Green: The current throughput rate; represents the number of requests per minute handled by the server.
The performance of Google server can be analysed with below figure.
We should focus on 2 parameters, to analyze the performance of the web server under test, i.e.
The Throughput is the most important parameter. The higher is the Throughput, the better is the server performance.
Here, the throughput of Google server is showing 1,491.193/minute, which means Google server can handle 1,491.193 requests per minute. It is a quiet high value, so we can conclude that Google server has good performance.
The deviation shown in red – indicates the deviation from the average. The smaller is the better.
Likewise we can test the performance of other sites also, like ‘yahoo’ http://www.yahoo.com/.
It shows the throughput value 867.326/minutes which is quiet lower than Google. Also, the deviation is much higher (2689) than Google (577). So, we can conclude the performance of ‘Yahoo’ is less than ‘Google’ server.
NOTE: Several factors are involved in the above values like current server load at google, internet speed, CPU power etc. So, it’s very unlikely that we will get the same results as above.
If you face the issue while running above test then follow these ‘Troubleshooting’ steps :
- Check whether connecting to internet via a proxy. If yes, remove the proxy.
- Open a new instance of JMeter
- Open the PerformanceTestPlan.jmx in Jmeter
- Double Click on Thread Group → Graph Result
- Run the Test
With above discussion and steps, you can check your website performance with JMeter Load testing.
At TBI we have a skilled and experienced team of QA testers who can effectively check your website performance and also guide you with the necessary tips to improve it better.
If you have any query or want to consult with us about your Website or App performance load testing, then feel free to Reach us or write us at firstname.lastname@example.org. We would be pleased to contact you soon.
If you have found above resource useful, then please do share your comment with us below :