Tuesday, November 13, 2018

Distributed (Remote) Testing Using Jmeter

JMeter: Distributed (Remote) Testing

JMeter is popular open source load testing software from Apache and it is a Java Graphical application. The easiest way to run it in Amazon EC2 is in a windows server so it could be easily access via RDP.

JMeter has a master/slave architecture where the client is the master and multiple JMeter servers are slaves running tests in a scalable fashion. I tried to set up an environment where the master instance would be hosted by my workstation behind corporate firewall but due to the corporate polices with regards to setting up inbound rules in the firewall it proved to be a challenge.

So, I gave up and went with the approach where I set up  both the master and client(s) in Amazon EC2, the master on a large instance so it has the CPU to process the graphs and the slave(s) on medium instances that have the network capacity to run the tests.
In order to be able to set up distributed environment you have to have some basic knowledge of how to spin up and Amazon server image and set up security groups (and the concept of AWS security groups). You have to be logged into AWS console in order to accomplish it.

Before we dive into the step-by-step instructions, it's a good idea to define the terms and make sure the definition is clear.
Master– the system running Jmeter GUI, which 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 to stress test

Important notes

Make sure that all the nodes (client and servers) :
  • are running exactly the same version of JMeter.
  • are using the same version of Java on all systems. Using different versions of Java may work but is discouraged. I had to download in install the same version of JDK across all servers that I used in the test.
If the test uses any data files, note that these are not sent across by the client so make sure that these are available in the appropriate directory on each server. In my test, on the server machine I had to define the following path, that I had defined in the 'User Defined Variables' section of my Java script.

Step-by-step guide

  • Log in AWS console.
  • Define two security groups, one to be used by the master and another one by the slave. Go with default values, you will tailor them later once you have spun up the server images.
  • Pick an Amazon Windows Image. In my case I selected  64 bit Windows 2008 R2 Server image (the same was selected for the second image). Launch a large instance (for the master). Take note of its public IP addresses. In my case I had ''. Make sure that port 3389 (security group) open for RDP, the same would apply for the second image (see below)
  • Launch a medium instance to be used as a host for a slave. In a case when a few slaves are required then more instances should be launched. Take note of their public IP addresses. I spun a single instance with the following IP address: ''
  • Edit the (master) security group with the following inbound rule (see the screenshot below). The IP address of the slave's host should be used with the CIDR notation, that is the /32 prefix should be appended to the IP address. Note, I picked an arbitrary port 51000. Could be any port as long as it is not in use by any other process. Once you have edited it, the changes will be applied on the fly to the created image.
  • This port would be used to transfer test results from the slave server over to the master.
  • Edit the (slave) security group with the following inbound rule (see the screenshot below). The IP address of the slave's host should be used with the CIDR notation, that is the '/32' prefix should be added to the IP address. Note, I picked an arbitrary port 4000. Could be any port as long as it is not in use by any other process.
  • This port will be used for the master server to pass a set of test instructions to the slave machine. The master will be listening to this one port only to receive results. That means that all of the slaves will be sending their results back through this port.
  • Now, navigate to the slave host and into the [JMETER_HOME]/bin directory. Open jmeter.properties file and make sure to edit the following properties in the Remote hosts and RMI configuraion section of this file:
  • Now, on the slave host in the same [JMETER_HOME]/bin directory launch the JMeter application via command line, making sure to pass the public IP address of the slave's host. YOu are going to end up with the following output:

  • On the master machine similar to step one edit a few properties as indicated below in the jmeter.properties file
  • On the master machine launch JMeter GUI and select the  slave's host in the shortcut menu which should get the test going:


Hope this information will be useful, please provide your valuable feedback/suggestions !! Happy Testing.

Wednesday, March 21, 2018

Essential Skills for Performance Tester

Based on the discussion we had among the experienced performance testers/ engineers we came up with the essential skills that is required to be in Performance Testers

17 essential skills for growing web performance engineers
Requirement Gathering and System Level Skills:

1) Able to Understand the System Architecture (Knowledge of components ,OS , techology etc)
2) Have Basic understanding of System hardware Resource Like CPU , Memory, Network, Disc etc
3) Should Know about the Diffrent Types of Test Environments
4) Able to Know and understand  Functional Level Workflows
5) Able to gather information about Scenario of Currnt Production Load and Expected Load
6) Able to gather the information about SLAs

Scripting and Testing Skills:

1) Able to Install and Configure testing tools
2) Able to record and enhance the scripts
3) Understand and Prepare the Test Data
4) Able to create different scenarios (Load,Stress, real Life ) based on the expectations
5) Running the load test executions for the above created scenarios

Monitoring and Result Analysis Skills:

1) Able to analyze the load test tool results
2) Configure server monitoring counters
3) Bottleneck Identification
4) Reporting

Feel free to add in comments if i have missed anything

Tuesday, January 9, 2018

Using JSON extractor in Jmeter: How to deal with dynamic values in JSON response

How To use JSON Extractor in Jmeter

Json extractor is used like regular expression extractor to capture some dynamic values from the response but used for json only.

By using this we can fetch the values of variables in the Json.

Let me take an example

Below is the Json and its corresponding response:

Here we want to extract the value of variable name "label" or "val"
 which are changing dynamically

We can use Json extractor to fulfil thie purpose here

below is the JSON values that can be used

In this Json extractor blow are the parameters and their corresponding values

Variable Name: Name of the variable (can be used anything logical, here we have used the same as we are getting in response)

JSON Path expression: It is the most important part for JSON configurations, We should use the path extractor expression here.
 Here we have used $..lable , Here two dot means we have json variable in two nested blocks, For normal JSON where there is only one tag , we used single dot.

Match Number: 0 means any random value, here we can use 1 or 2 to get first value or second value and so on, we can also use -1 for getting all possible values to be stored in array (with variable name as mentioned above)

Default Values: this values that can be passed when we didnt got the expected value.

TO varify the value captured in Json extractor:

We can use the Debug Sampler on the thread group to validate the value captured using Json extarctor, Debug sample is used to print all the used defined configured variable in jmeter.

Here we can see that variable "label": captured SpiceJet , and lable_matchNr having value as 10 because there are 10 occurrence of the values corresponding to the expression we have defined for variable label in JSON extractor.

Feel Free to add if i have missed anything.