Performance Testing in the Cloud with JMeter

Author : Published Date : December 14, 2016

Tag List : , , ,

JMeter

JMeter, along with it’s out of the box features is an open source software entirely designed on Java application to stress test websites and your application architectures. JMeter can simulate multiple users with concurrent threads, creating a heavy load against web application under test.

For instance, one M4 Large instance will be sufficient to serve 250 requests per seconds. Nevertheless, stimulating additional users would require launching of more than one JMeter instances by setting up clusters with multiple machines.

Nonetheless, in a situation where everybody is migrating onto the cloud to get a handle on the paradigm shift of the technology, the pay-as-you-go model has become a trend instead of on-premise reserved servers. This, in turn, becomes a limitation for JMeter, regardless of the fact that JMeter supports countless testing strategies such as Load Testing, Distributed Testing, and Functional Testing.

JMeter uses Java RMI (Remote Method Invocation) to communicate to its slaves, but these connections require all the servers on the same subnet, which is not a feasible option while using EC2 instances.

Below, is a short tutorial to resolve this problem using a 3 node configuration in AWS to execute tests assuming that the test has already been written in the .jmx file.

However, before we dive into the step-by-step instructions, let’s take a glance at the definition of some important terms.

  • Master – The system running JMeter GUI, which controls the test
  • Slave – The system running JMeter-server which takes commands from the GUI and sends requests to the target system(s)
  • Target – The web-server we plan to stress test

Master Slave Target

Going ahead, there is one master instance that sends the test to 2 slaves. These slaves execute the test and send the results back to the master to collect and combine the results.

Note:*

  • The test will be executed on both slave machines and not divided across them.  This means that if one wants to run 300 threads in the test, the target will be hit with 600 threads.
  • The master does NOT execute any tests. Gathering the results and orchestrating the tests is enough to handle for one machine.
  • The test will be sent out to the slaves from the master.  There’s no need to copy the test file to all slaves.

 

Running JMeter on Remote:

Before starting with remote testing, following points are to be considered:

  1. The firewalls on the systems are turned off.
  2. All the clients are on the same sub-net.
  3. The server is in the same subnet, if 192.x.x.x or 10.x.x.x IP addresses are used. If the server doesn’t use 192 or 10 IP address, there shouldn’t be any problems.
  4. Make sure JMeter can access the server.

4.1 Turn on Sharing from “My computer> Properties> Advance System settings> Remote> Remote Assistance” AND

4.2 Turn on Sharing settings from “Control Panel> Network and Internet> Network and Sharing Center> Advanced sharing settings”

  1. Make sure you use the same version of JMeter on all the systems. Mixing versions may not work correctly.
  2. Make sure you have changed the option to Computer sleeps from “Control Panel>Hardware and Sound>Power Options>Edit Plan Settings” for all machines (Master and Slave/s) to Never.

Testing

 To confirm the communication in channel: try to Ping from Slaves to Master and Master to Slaves, once.

 Following settings below are also to be considered before proceeding to remote testing:

  1. Go to JMeter bin folder
  2. Open “jmeter.properties” file in Edit mode
  3. Go to “# Remote hosts and RMI configuration” section
  4. Mention the IP address/es of Slaves as a value for “remote_hosts” and make sure you have uncommented the same.

e.g: remote_hosts=10.1.1.144,10.1.1.35,10.1.1.56,10.1.1.34,10.1.1.140

 

Note: Make sure to update this line in each run for the slaves included in the test with correct IP.

Mention “server.rmi.create=false” for Master AND “server.rmi.create=true” for Slave/s

Uncomment “mode=Asynch”

Uncomment “asynch.batch.queue.size=” and update the value to 250

e.g.: asynch.batch.queue.size=250

(This setting denotes that if the machine IP is used as SLAVE; it will serve 250 users max to run on.)

 

Now, as all the points have been considered and the settings have been done, let’s run .jmx file remote from the command line:

 

NOTE: Make sure you have started the remote servers before running test.

 

  1. Open command line from jmeter/bin
  2. Enter the following command:

jmeter -n -t myjmetertest.jmx -l myjmetertest_10users.jtl -R ipnumber1,ipnumber2

Running JMeter on Remote from UI:(NOT recommended for big tests)

NOTE: Make sure you have started the remote servers before running test.

  1. Open jmeter GUI
  2. Open jmx file you would like to run on the remote and add necessary listeners to Test Plan.
  3. Click on “Remote Start all” button from the top.

Latest posts by Yogesh Dawkhar (see all)

We’d love to

hear from you!

We’d love to

hear from you!

Leave a Comment

× 5 = 50