Detail Description of JMeter Components

Here is a Detailed Review of JMeter Components (Part- II). In this tutorial, readers will get an understanding of all JMeter components and how to use them in the test plan to cover all possible performance testing scenarios to test the AUT (Application Under Test).

=> This is part of the JMeter training series. See the list of all tutorials in this series here.

Hope you all must have gone through the JMeter Introduction and Installation by now. As we continue with the next one in the series, it is highly recommended that you all must install JMeter and practice side by side.

Components of JMeter

Elements of Jmeter had been listed down in the previous article.

I have listed them here again for your reference:

• Test Plan
• ThreadGroup
• Samplers
• Listeners
• WorkBench
• Assertions
• Config Element
• Logic Controllers
• Timer

All major components of Jmeter such as Thread Group, Samplers, Listeners and Config Elements are explained in detail later in the article.

Please refer to the below flow diagram to understand each component and their relation to specific modules of JMeter.

We will now start touching each component of Jmeter along with use cases just to see how it works and how testers can implement these in their testing. Please note that we won’t be covering all Samplers and listeners in this article. We will work on the most used ones and will take up the rest in the next article when we create real time Test Plans.

Test Plan

Just as a simple test plan in Software Testing consists of all steps which execute the script, JMeter’s Test plan has the same purpose. Everything that is included in the test plan is executed in a sequence that is top to bottom or as per the defined sequence in the test plan.

The Test Plan can be as simple as it can be, with Just ThreadGroup, Sampler, and Listener and it starts getting more complex as soon as you start adding more elements like config elements, preprocessors or controllers.

As we all know, JMeter measures performance by generating Virtual Users and Threads which hits the server under test as if real users are sending requests to a server. Therefore, every Test Plan should have virtual users or Thread Group as we call them in JMeter’s terms.

A Few Important Points about Test Plan:

• The test plan should be saved before running
• Jmeter files and test plans are saved in the form of. JMX extension files
• You can also save parts of the Test Plan as different selections. For example, if you want to save the HTTP Request Sampler with Listener, you can save it as Test Fragment so that it can be used in other test scenarios as well
• Elements of WorkBench are not saved with Test Plan

Thread Group

Thread Group is a group of users who will be hitting the server under test either concurrently or in some predefined sequence. It can be added to the Test Plan by right clicking on the test plan. JMeter is all “Right Click stuff”, you get all the options on the right click.

You can rename the Thread Group name to your own. Just change your name and click anywhere outside the Test Plan window and you will see the name getting changed.

Please see below screenshot for adding Thread Groups

(Note: Click on any image for an enlarged view)

It is very important to configure your thread group as per the test conditions.

For example, if you want to test how a web server behaves when 100 user hits it concurrently, you can set the Thread Group as below:

Basically, there are three main parameters which must be configured to generate actual load or virtual users:

• Number of Thread(Users) – It defines the number of virtual users. For testing purpose, we should generate only a limited amount of load as generating huge volume at once would mean consuming a lot of many threads which can ultimately lead to high CPU utilization.
• Ramp Up Period – This field is very important in controlling load generation. Ramp up period defines the amount of time in which the total load will be generated.

Example 1:

• This means all 10 users will be hitting servers concurrently as soon as a test is run

Example 2:

• You may have noticed the “Scheduler” checkbox in the above screenshot. In case you want your test to run at a specific time later then you can set the timings as you can also see in the below screenshot. This means that every 1 sec, a new user will be hitting the server. The load will not be concurrent but will be in increments. By the 10^th second, all users would have hit request.
• Loop Count – It defines the number of times the Thread Group will execute. If you check the Forever check box your test will run forever unless you manually stop it. This can be used to test something like “If your server doesn’t crash on continuous load for few minutes”.

Samplers

So, how does a Jmeter know what type of request has been sent to the server???

• It is through Samplers. Samplers are a must to be added to a Test Plan as they can let the Jmeter know what type of request needs to go to which server and with any predefined parameters or not. Requests could be HTTP, HTTP(s), FTP, TCP, SMTP, SOAP etc.

Samplers can only be added to the Thread Group and not directly under the Test Plan as Thread Groups need to use a sampler to send a request to the server URL under test. The sampler can be added by the path Thread Group -> Sampler -> HTTP Request.

HTTP Requests

These are the most common requests sent to the servers. Say, for example, we want 100 users to hit https://www.google.com concurrently, this can be done as described in the below screenshot:

• The path is the navigation inside the main website. For example, if we want to hit http://www.google.com/gmail then we can set “/Gmail” in path and the rest remains the same.
• Need not type “www” in the server name
• Port Number is used if you are using any proxy server
• Timeout Connect and Response can be set if you want to have a benchmark on your server connection time and response time. Your request will fail if your server takes more time to send a response than the configured one
• You can also configure parameters to send with your request. For example: In some cases, you may need to send an Authorization Token with your request, so you made add them to the HTTP Request below:

FTP Requests

Path-> Test Plan-> Thread Group-> Sampler-> FTP Request

FTP stands for File Transfer Protocol and it is used to upload or download a file from the server. JMeter’s thread sends requests to FTP servers to upload or download files from there and measure their performance.

• Local File is the location where you need to save the downloaded file
• Use GET option if you are downloading from FTP server
• User POST option if you are uploading any files on FTP server

We have a lot of listeners that will be covered when we go through some real Test Plans consisting of Samplers, listeners, config elements etc.

Listeners

So, till now we have seen a few samplers sending requests to the server but haven’t analyzed the response yet. Performance testing is all about analyzing server responses in various forms and then presenting the same to the client.

Listeners are used to display the results of test execution so that testers get to know the stats. We have around 15 listeners in Jmeter but the most used are Table, Tree, and Graph.

View Results in Table:

This is the most commonly used and easily understandable form of listeners. It displays the results in the form of a table with some important performance parameters.

Listeners can be added directly under the Test plan or under a sampler. The difference is, when you add listener under a sampler, it will show the results of that sampler only.  If we add a sampler directly under the test plan, it displays the results for all the Samplers up in the hierarchy.

Screenshot below for your reference:

See the results, something like the ones displayed below:

• Latency: When the first piece of information is received i.e. the first byte of data is received
• Connect Time: It is the time taken to establish connection with the server
• Sample Time: Time taken to receive complete data
• Sample – Sequence of sample number
• Bytes – Size of data received.

View Results in Tree:

This is another of the most commonly used listeners and provides detailed information with requests and responses. One can also view the HTML page rendered in response apart from viewing Json, XML, Text, RegEx.

It is very useful as testers can put assertions on the response received to ensure that the test passed. Jmeter results still show “Pass” even if the response is not desired.

For Example: Say, we hit HTTP request on any website www.xyz.com and in response we expect <title> XYZ </title> or in simple words, when we hit this page company’s home page opens with its name. If we don’t put assertions, JMeter will still display results since the hit has gone to the server.

Please see below to find out the format of the results:

To view the HTML page in your response, click on the drop-down in the left pane, and then select “HTML”, Navigate to the response tab and check the page which is returned as the server’s response.

Work Bench

A workbench is a place where you can store those elements which are not in use in your current test plan but which can be later copy pasted in it. When you save JMeter file, the components that are present on the workbench are not automatically saved. You must save them separately by right clicking and choose “Save as “option.

You all might be thinking then what is the use of the workbench, anyways it is easy to add any component directly to a Jmeter’s Test Plan.

The reason for having a workbench was that the user could do some experiments and try out new scenarios. As we already know elements on the workbench are not saved so a user can literally use anything and then throw it away. But, there are some “Non-Test Components” which are only available in WorkBench.

They are listed here:

• HTTP Mirror Server
• HTTP(s) Test Script Recorder
• Property Display

HTTP(s) Test Script Recorder is the most important Non-Test Element used in JMeter. It helps testers in recording the script and then configuring the load for each transaction.

Jmeter only records the request sent to the server. Don’t get confused with “Record and Play” functionality of QTP/Selenium.  All requests are recorded and testers can apply the desired load to them to see the behavior.

This element is very important for scenarios where testers don’t know what all requests are going on from their application. They can use the Http(s) script recorder to record the application under testing.

Performance Testing of mobile applications can also be done in this way by setting up JMeter proxy and then recording the requests which our mobile app sends to the server. The Step by Step procedure for mobile performance testing will be explained in the next article.

Assertions

Till now, we have covered how JMeter hits the server and how the responses are displayed via listeners. To ensure that the response received is correct and as per expectations, we need to add assertions. Assertions are simply validations which we need to put on responses to compare the results.

Below are the types of assertions commonly used:

• Response Assertion
• Duration Assertion
• Size Assertion
• XML Assertion
• HTML Assertion

Response Assertion

In the Response Assertion, we can add our own pattern strings and then compare them with the responses received from the server. As you all know, the response code is 200 when any request returns a response successfully. So, if we add pattern string “Response Code = 202” then the test case should fail.

Please refer to the screenshots below to add the Response Code assertion.

Now, when the test runs it shows the result with Red Color indicating that the Assertion results have failed.

Duration Assertion

Duration Assertion is very important and validates that the server responded within a given amount of time. This can be used in scenarios where we need to sample 100 requests and ensure that every response is received within the benchmarked limit.

Case: 10 users are concurrently hitting “google.com” server and Duration Assertion is set to 1000ms.Please see below screenshots:

XML Assertion validates if response data has the correct XML document in it and HTML Assertion verifies the HTML syntax of the response received from a server.

Config Elements

Requests sent to the server can be further parameterize using some config elements which are executed before the actual request. A simple example of this could be the reading values of a variable from a CSV file for which CSV Data Set Config is used.

Below are some of the important config elements used in the performance testing of the web and mobile applications

• CSV Data Set Config.
• User Defined Variables
• HTTPS Requests Default
• HTTPS Cache Manager
• HTTPS Cookie Manager

CSV Data Set Config

CSV data set config helps Jmeter in picking values of some parameters from a CSV file rather than passing different parameters in each separate request. For example, if we need to test login functionality with a different set of users and passwords, then we can create two columns in a CSV file and enter the values there so that JMeter can pick one for each request sent to the server.

Below is the flow of using CSV data set config to test weather API for different cities in India.

• Adding CSV data set config element to test plan

• Create CSV file
• Passing the variable in the request parameter. The APPID parameter can be generated dynamically from http://openweathermap.org/appid

• Run the test and view the results.

User Defined Variables

It helps Jmeter to pick values from a pre-defined variable. For example, support that you need to create a test plan in which you need to add many HTTP requests to the same URL and there could be a scenario in which client plans to migrate it later to some different URL. To avoid updating URL in each request, you can tell JMeter to pick the URL from a UDV (User Defined Variable) which can be updated to the URL.

To avoid updating URL in each request, you can tell JMeter to pick the URL from a UDV (User Defined Variable) which can be later updated to handle all requests to the updated URL.

HTTP Request Defaults

This config element is very useful for specifying the default values of https requests.  To guide you further, let’s look at an example where we need to hit 50 different requests on the Google server. In this scenario, if we add an HTTP Request Default then we do not need to specify the server name, path or any other property like port number, connection time out properties. Whatever is specified in the HTTP Request Default config element is inherited from all HTTP requests.

In this scenario, if we add an HTTP Request Default then we do not need to specify the server name, path or any other properties like port number, connection time out properties. Whatever is specified in the HTTP Request Default config element is inherited from all HTTP requests.

Please see below how to add HTTP Request Default and specify server and path.

HTTP Cache Manager and HTTP Cookie Manager are used in making JMeter behave as a real-time browser. The HTTP Cache manager can clear the cache after each request whereas the other one can manage the cookie settings.

Logic Controllers and Timers

Logic controllers and timers help Jmeter control the flow of transactions. Timers to ensure delay in each thread if we need to test any server. For example, if we need an FTP request to wait for 5 secs after the HTTP request is completed, we can add a timer there.

Logic Controllers are used to define the flow of requests which are sent to the server. It will also allow you to store requests for each module separately such as login and logout.

Conclusion

By now, you all must have got yourself familiar with the components of JMeter and have tried using it and must be facing some issues. In the next article, we will be covering some real-time performance testing scenarios covering the mobility domain so that you all get more hands-on knowledge on JMeter.

Stay Tuned! The next article will help you manage your requests as well as analyzing results and comparing with the benchmarks of performance testing.

=> Continue reading part-III: JMeter Processors and Controllers

=> Click here for the JMeter Tutorials: Complete Free Training On JMeter (20+ Videos)