Documente Academic
Documente Profesional
Documente Cultură
APACHE JMETER
The Complete Guide to Test the Performance
of Web Applications
Introduction to Apache JMeter
Preface
Table of Contents
What is Apache JMeter ................................................................................................................................. 5
How does Apache JMeter work? .............................................................................................................. 5
Prerequisite of JMeter ........................................................................................................................... 6
How to Download JMeter ............................................................................................................................. 8
Steps to Launch JMeter ................................................................................................................................. 9
Configuration Element ............................................................................................................................ 11
CSV Data Set Config: ......................................................................................................................... 12
HTTP Request Defaults: ..................................................................................................................... 13
User Defined Variables (UDV): ......................................................................................................... 14
HTTP Cookie Manager ....................................................................................................................... 14
Build JMeter Test Plan................................................................................................................................ 15
Add and Remove Test Plan Elements ..................................................................................................... 16
Steps to Add Elements to JMeter Test Plan ........................................................................................ 16
Steps to Remove Elements from JMeter Test Plan ............................................................................. 17
Load and Save JMeter Test Plan Elements ............................................................................................. 18
Steps to Load Elements to JMeter Test Plan Tree .............................................................................. 19
Steps to Load Elements to JMeter Test Plan Tree .............................................................................. 19
Steps to Configure Tree Elements ...................................................................................................... 20
JMeter Actions on Test Plan ................................................................................................................... 21
Steps to Save JMeter Test Plan ........................................................................................................... 21
Steps to Run JMeter Test Plan ............................................................................................................ 22
Steps to Stop to JMeter Test Plan ....................................................................................................... 22
Steps to Check JMeter Test Plan Execution Logs .............................................................................. 22
What is Thread Group in JMeter? ............................................................................................................... 23
How to Create a Thread Group Element in JMeter Test Plan? ................................................................... 25
Components of Thread Group ................................................................................................................ 25
1) Action to be taken after a Sampler Error ........................................................................................ 25
2) Thread Properties ............................................................................................................................ 26
3) Scheduler Configuration ................................................................................................................. 26
Building a Web Test Plan ........................................................................................................................... 27
Adding Users .......................................................................................................................................... 27
Adding Default HTTP Request Properties.............................................................................................. 29
Stefano Mazzocchi of the Apache Software Foundation was the original developer of JMeter. He
wrote it primarily to test the performance of Apache JServ (currently known as Apache Tomcat
project). Apache redesigned it to enhance the GUI, to add more features and functional testing
capabilities.
JMeter Features:
Now we will learn How to Download and Install JMeter. But before going to this there are set
of prerequisites.
Prerequisite of JMeter
1) Java Requirements:
JMeter is a 100% pure Java application, it requires a fully compliant JVM 7 or higher. If you do
not have Java installed on your system, you can download and install the latest version of Java
Software Development Kit (SDK) or Java Runtime Environment (JRE) from here or you can
follow the Step by Step Tutorial on Tools QA.
To verify Java installation, run java -version command from your command prompt. If Java is
successfully installed on your system, you would be able to see the following output on your
command console. In our tutorials, we are using Java 8.
In case you see the following screen, maybe JDK/JRE is not installed correctly on your system.
Or maybe you need to set system environment variables. Please foolow the tutorial on ToolsQA
for Step by Step process to Set up Java Environment Variable Path.
If your Operating system supports java, then JMeter should run correctly on your system. Below
mentioned operating systems have compliant Java implementation:
For more details on compatibility concerns related to Operating system and JVM, please refer
the following link: http://wiki.apache.org/jmeter/JMeterAndOperatingSystemsTested
2) Once it is downloaded, it will by default save to the Downloads folder of your system.
3) Unzip the file on to your desired path. JMeter Directory Structure looks like this:
Point 1 : Bin folder contains templates, .bat, .sh, .jar files to start JMeter. It also contains User
& JMeters properties files.
Point 2 : Lib folder contains all required jar files.
After launching, you will be able to see JMeter main screen after few seconds.
Configuration Element
enable us to declare variables, so Samplers can use data through these variables. Configuration
element is accessible from only inside the tree node where you defined it. Also, if a configuration
element is defined inside a tree node, it will have high precedence than the same configuration
element which is defined in a parent node.
Counter
CSV Data Set Config
DNS Cache Manager
FTP Request Defaults
HTTP Authorization Manager
HTTP Cache Manager
HTTP Cookie Manager
HTTP Header Manager
HTTP Request Defaults
Java Request Defaults
JDBC Connection Configuration
Keystore Configuration
LDAP Extended Request Defaults
LDAP Request Defaults
Login Config Element
Random Variable
Simple Config Element
TCP Sampler Config
User Defined Variables
CSV Data Set Config element is used to read data from a text or CSV format file. For Example,
If you need to perform load test of login scenario with 100 unique users. Prepare the data in CSV
file with 100 user records with username and password, and you can use this file data in every
thread through variables in your requests/samplers by using this configuration element.
Following is the sample text file which contains user credentials for login scenario:
HTTP Request Defaults Configuration Element let us set default values to be used in HTTP
Request Samplers.
For Example: You need to send 100 HTTP Requests to the same server, then you can utilize
HTTP Request Default element with your Server Name or IP. Now, there is no need to give
Server Name or IP in all 100 HTTP Requests explicitly. The requests will get Server Name or
IP from the HTTP Request Default, just give the relative path of the web pages in
samplers/requests.
User Defined Variables Element let us use default variables and values in the test plan. If you
need to use UDV in only one Sampler, then define it under that Sampler. If you need to use UDV
in multiple parts, then define it at the start of Test Plan.
HTTP Cookie Manager is used to store cookies which targeted server sends in the response of
your Http request. The saved cookies can be used in other samplers/requests of the Test Plan.
1. You can also add User Defined Cookies; these cookies will be shared to all the Threads.
2. Cookies can be seen using the View Results Tree Listener.
3. Such Cookies usually have Expiration time far in the future.
Lets start building test plan by launching JMeter by following these two steps:
Go to your JMeter bin folder e.g. E:\apache-jmeter-3.0\bin
Double click ApacheJMeter.jar file.
Now, you can see the following JMeter GUI after a short break.
Property Display. If you need to save it along with the test plan, then you should select
the option Save WorkBench from WorkBench control panel.
After renaming test plan and defining variable, JMeter will look like as follows:
After adding Thread Group element, you can see the following screen:
Note : Elements can also be loaded from a file and added by selecting the merge or open
options.
When you add number of Elements to Test Plan, you may like to remove one which is not
required any more. That can be done by following the below steps:
1. Select and right click on any Tree Element, in which you want to add the loaded element
2. Select Merge option
3. Choose the .jmx file where you saved the elements
4. Elements will be Merged into the tree
5. Dont forget to Save test plan / element
JMeter will save the element, and all the child elements beneath it.
Elements can be configured by using controls present on JMeters right hand side frame. The
controls allow us to configure behaviour of the selected element. The configuration varies from
element to element.
E.g. Thread Group can be configured for Number of Threads, Ramp-Up Period, and
Scheduler etc., as shown below:
Its always better to Save Test Plan before executing it. Test Plan can be saved by choosing
Save or Save Test Plan As from File menu.
Note: WorkBench will not be saved along with the Test Plan, you should select the option Save
WorkBench from WorkBench control panel otherwise your WorkBench data will be lost.
Test plan can be run from the Run menu item or by clicking Green Play button.
1. Stop (Control + .) It stops the threads immediately if possible. Many samplers are
interruptible so active samples can be terminated early.
2. Shutdown (Control + ,) It requests the threads to stop at the end of any ongoing task. It
will not interrupt any active samples.
JMeter stores test run details, warnings and errors to the jmeter.log file by default, you can
access JMeter logs for debugging purpose.
Now we learn Thread Group in JMeter Test Plan, we will be covering the following topics:
To understand the JMeter Test Plan, please visit the previous tutorial (Building Test Plan in
JMeter) of this series.
Thread Group elements are the initial steps of JMeter Test Plan. A number of threads (users)
can be defined in a Thread Group. Each thread simulates a real user requesting to the server
under a test.
If you set the number of threads as 20; JMeter will create and simulate 20 virtual users during the
load test. A diagram here can help us understand it better
Start JMeter
Select Test Plan on the tree
Add Thread Group
Open the thread group panel by Right Click on Test Plan and then going to Add >> Threads >>
Thread Group. As shown in the image below:
If JMeter catch any sampler error during test execution, you can tell it how to react in that
scenario from the following available options.
Continue, to ignore error and move to the next element in the tree
Start Next Thread Loop to stop current Thread and Start Next
Default is Continue.
2) Thread Properties
Number of Threads (users): Simulates the number of users or connections to your server
application.
Ramp-Up Period (in seconds): Tells JMeter how long to take ramp-up to the full number
of threads chosen. For Example: If you set Number of Threads to 20, and Ramp-
Up Period to 40 seconds, then JMeter will wait till 40 seconds to make all threads up
and running. That means each thread will start 2 seconds late after the previous thread
was started.
o Formula: Ramp-Up Period / Number of Threads i.e. 40 / 20 = 2 (seconds)
Loop Count: the number of times the test to be executed. If you need to run the test
forever, then select the Forever check box.
Scheduler: To schedule test execution. Scheduler Configuration bottom panel will get
enabled when you select this checkbox. The schedule feature is also very helpful in
soak/endurance testing.
3) Scheduler Configuration
You can configure test start time, end time, duration and start up delay of your load test plan
using Scheduler Configuration section. To enable this area of configuration, Scheduler check box
must be selected from the above Section of Thread Properties.
Start Time: This plans the test to start at scheduled time. Pre Condition is that the
JMeter should be running on given date and time in Start Time field.
End Time: This command JMeter to end the test at the mentioned time. End time
override and stop execution in between. Means End Time is maximum allowed time to
finish execution of the test plan. JMeter ends the execution immediately as soon as End
Time is occur.
Duration (seconds): This tell the JMeter to execute the test for the specific duration of
time. If the duration is set to 60 secs, JMeter will keep the execution on for 60 secs and
ends it once the time is elapsed. It also ignores or override the End Time and All threads
has completed its test or not.
Startup delay (seconds): This tells JMeter to wait for specified time before starting the
test. If the StartUp time is set to 10 secs, JMeter will not start loading the Users till the
time 10 secs are over.
For a more advanced Test Plan, see Building an Advanced Web Test Plan.
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and how many requests they should send.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the
right section of the JMeter window (see Figure 4.1 below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter
JMeter Users.
In the next field, the Ramp-Up Period, leave the default value of 1 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up
Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So,
if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would
be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will
immediately start all of your users.
Finally enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. If you enter a loop count value of 1, then JMeter will run your test only once. To
have JMeter repeatedly run your Test Plan, select the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
See Figure 4.2 for the completed JMeter Users Thread Group.
Begin by selecting the JMeter Users (Thread Group) element. Click your right mouse button to
get the Add menu, and then select Add Config Element HTTP Request Defaults. Then
select this new element to view its Control Panel (see Figure 4.3).
Like most JMeter elements, the HTTP Request Defaults Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
Skip to the next field, which is the Web Server's Server Name/IP. For the Test Plan that you are
building, all HTTP requests will be sent to the same Web server, jmeter.apache.org. Enter this
domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The HTTP Request Defaults element does not tell JMeter to send an HTTP request. It simply
defines the default values that the HTTP Request elements use.
See Figure 4.4 for the completed HTTP Request Defaults element
To add the HTTP Cookie Manager, simply select the Thread Group, and choose Add Config
Element HTTP Cookie Manager, either from the Edit Menu, or from the right-click pop-up
menu.
JMeter sends requests in the order that they appear in the tree.
Start by adding the first HTTP Request to the JMeter Users element (Add Sampler HTTP
Request). Then, select the HTTP Request element in the tree and edit the following properties
(see Figure 4.5):
Next, add the second HTTP Request and edit the following properties (see Figure 4.6:
Select the JMeter Users element and add a Graph Results listener (Add Listener Graph
Results). Next, you need to specify a directory and filename of the output file. You can either
type it into the filename field, or select the Browse button and browse to a directory and then
enter a filename.
Logging in to a web-site
It's not the case here, but some web-sites require you to login before permitting you to perform
certain actions. In a web-browser, the login will be shown as a form for the user name and
password, and a button to submit the form. The button generates a POST request, passing the
values of the form items as parameters.
To do this in JMeter, add an HTTP Request, and set the method to POST. You'll need to know
the names of the fields used by the form, and the target page. These can be found out by
inspecting the code of the login page. [If this is difficult to do, you can use the JMeter Proxy
Recorder to record the login sequence.] Set the path to the target of the submit button. Click the
Add button twice and enter the username and password details. Sometimes the login form
contains additional hidden fields. These will need to be added as well.
For an example of a basic Test Plan, see Building a Web Test Plan.
To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the
server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier
to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it
will find it and add it to each request. If the request already has a value, it will be replaced. If
"Cache Session Id?" is checked, then the last found session id will be saved, and will be used if
the previous HTTP sample does not contain a session id.
Download this example. In Figure 1 is shown a test plan using URL rewriting. Note that the
URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect
requests under that SimpleController.
In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to
specify the name of the session ID parameter. There is also a checkbox for indicating that the
session ID should be part of the path (separated by a ";"), rather than a request parameter
The HTTP Header Manager, like the HTTP Cookie Manager, should probably be added at the
Thread Group level, unless for some reason you wish to specify different headers for the
different HTTP Request objects in your test.
This example uses the MySQL database driver. To use this driver, its containing .jar file (ex.
mysql-connector-java-X.X.X-bin.jar) must be copied to the JMeter ./lib directory (see JMeter's
Classpath for more details).
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and the how many requests they should send.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the
right section of the JMeter window (see Figure 6.1 below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter JDBC
Users.
You will need a valid database, database table, and user-level access to that table. In the example
shown here, the database is 'cloud' and the table name is 'vm_instance'.
In the next field, the Ramp-Up Period, leave the value of 10 seconds. This property tells JMeter
how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 10
seconds, JMeter will finish starting all of your users by the end of the 10 seconds. So, if we have
50 users and a 10 second Ramp-Up Period, then the delay between starting users would be 200
milliseconds (10 seconds / 50 users = 0.2 user per second). If you set the value to 0, then JMeter
will immediately start all of your users.
Finally, enter a value of 100 in the Loop Count field. This property tells JMeter how many times
to repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
See Figure 6.2 for the completed JDBC Users Thread Group.
Begin by selecting the JDBC Users element. Click your right mouse button to get the Add menu,
and then select Add Config Element JDBC Connection Configuration. Then, select this
new element to view its Control Panel (see Figure 6.3).
Set up the following fields (these assume we will be using a MySQL database called 'cloud'):
Variable name (here: myDatabase) bound to pool. This needs to uniquely identify the
configuration. It is used by the JDBC Sampler to identify the configuration to be used.
JMeter creates a database connection pool with the configuration settings as specified in the
Control Panel. The pool is referred to in JDBC Requests in the 'Variable Name' field. Several
different JDBC Configuration elements can be used, but they must have unique names. Every
JDBC Request must refer to a JDBC Configuration pool. More than one JDBC Request can refer
to the same pool.
Selecting the JDBC Users element again. Click your right mouse button to get the Add menu,
and then select Add Sampler JDBC Request. Then, select this new element to view its
Control Panel (see Figure 6.4).
In our Test Plan, we will make two JDBC requests. The first one is for select all 'Running' VM
instances, and the second is to select 'Expunging' VM instance (obviously, you should change
these to examples appropriate for your particular database). These are illustrated below.
JMeter sends requests in the order that you add them to the tree.
Next, add the second JDBC Request and edit the following properties (see Figure 6.6):
Select the JDBC Users element and add a Summary Report listener
(Add Listener Summary Report).
Save the test plan, and run the test with the menu Run Start or Ctrl + R
To construct the Test Plan, you will use the following elements: Thread Group, FTP Request,
FTP Request Defaults, and View Results in Table.
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and the how many requests they should send.
Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the
right section of the JMeter window (see Figure 7.1 below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter 'FTP
Users'.
In the next field, the Ramp-Up Period, leave the default value of 0 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up
Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So,
if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would
be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will
immediately start all of your users.
Finally, enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
See Figure 7.2 for the completed FTP Users Thread Group.
Begin by selecting the FTP Users element. Click your right mouse button to get the Add menu,
and then select Add Config Element FTP Request Defaults. Then, select this new
element to view its Control Panel (see Figure 7.3).
Like most JMeter elements, the FTP Request Defaults Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
Skip to the next field, which is the FTP Server's Server Name/IP. For the Test Plan that you are
building, all FTP requests will be sent to the same FTP server, ftp.domain.com in this case. Enter
this domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The FTP Request Defaults element does not tell JMeter to send an FTP request. It simply defines
the default values that the FTP Request elements use.
See Figure 7.4 for the completed FTP Request Defaults element
JMeter sends requests in the order that they appear in the tree.
Start by adding the first FTP Request to the FTP Users element (Add Sampler FTP
Request). Then, select the FTP Request element in the tree and edit the following properties
(see Figure 7.5):
You do not have to set the Server Name field because you already specified this value in the FTP
Request Defaults element.
Next, add the second FTP Request and edit the following properties (see Figure 7.6:
Select the FTP Users element and add a View Results in Table listener (Add Listener
View Results in Table).
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and the how many requests they should send.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add ThreadGroup. You should now see
the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test
Plan tree by clicking on the Test Plan element.
Like most JMeter elements, the Login Config Element's Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
Like most JMeter elements, the LDAP Request Defaults Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
JMeter sends requests in the order that you add them to the tree. Start by adding the first LDAP
Request to the LDAP Users element (Add Sampler LDAP Request). Then, select the
LDAP Request element in the tree and edit the following properties
You do not have to set the Servername field, port field, Username, Password and DN because
you already specified this value in the Login Config Element and LDAP Request Defaults.
Next, add the second LDAP Request and edit the following properties
Next, add the Third LDAP Request and edit the following properties
Next, add the fourth LDAP Request and edit the following properties
Note: A this position in the tree, the Response Assertion will be executed for each LDAP
Request.
As the Extended LDAP Sampler is highly configurable, this also means that it takes some time to
build a correct Testplan. You can however tune it exactly up to your needs.
You will create four users that send requests for four tests on the LDAP server. Also, you will
tell the users to run their tests one time. So, the total number of requests is (1 users) x (9
requests) x repeat 1 time) = 9 LDAP requests. To construct the Test Plan, you will use the
following elements:
Thread Group, Adding LDAP Extended Request Defaults, Adding LDAP Requests, and Adding
a Listener to View/Store the Test Results
For the less experienced LDAP users, I build a small LDAP tutorial which shortly explains the
several LDAP operations that can be used in building a complex Testplan.
Take care when using LDAP special characters in the distinguished name, in that case (e.g. you
want to use a + sign in a distinguished name) you need to escape the character by adding an "\"
sign before that character. Extra exception: if you want to add a \ character in a distinguished
name (in an add or rename operation), you need to use 4 backslashes.
Examples:
cn=dolf\+smits
to add/search an entry with the name like cn=dolf+smits
cn=dolf \\ smits
to search an entry with the name cn=dolf \ smits
cn=c:\\\\log.txt
to add an entry with a name like cn=c:\log.txt
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and the how many requests they should send.
Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select AddThreads (Users)Thread Group. You
should now see the Thread Group element under Test Plan. If you do not see the element, then
"expand" the Test Plan tree by clicking on the Test Plan element.
Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name
field that you can modify. In this example, leave this field with the default value.
For each of the different operations, some default values can be filled in. In All cases, when a
default is filled in, this is used for the LDAP extended requests. For each request, you can
override the defaults by filling in the values in the LDAP extended request sampler. When no
value is entered, which is necessary for a test, the test will fail in an unpredictable way!
We will not enter any default values here, as we will build a very small testplan, so we will
explain all the different fields when we add the LDAP Extended samplers.
1. Thread bind
2. Search Test
3. Compare Test
4. Single bind/unbind Test
5. Add Test
6. Modify Test
7. Rename entry (moddn)
8. Delete Test
9. Thread unbind
JMeter sends requests in the order that you add them to the tree.
3. Enter the hostname value from the LDAP server in the Servername field
4. Enter the portnumber from the LDAP server (636 : ldap over SSL) in the port field
5. (Optional) Enter the baseDN in the DN field, this baseDN will be used as the starting
point for searches, add, deletes, etc.
take care that this must be the uppermost shared level for all your request, e.g. when all
information is stored under ou=Users, dc=test, dc=com, you can use this value in the
basedn.
6. (Optional) Enter the distinguished name from the user you want to use for authentication.
When this field is kept empty, an anonymous bind will be established.
7. (Optional) Enter the password for the user you want to authenticate with, an empty
password will also lead to an anonymous bind.
8. (Optional) Enter a value for the connection timeout with LDAP
9. (Optional) Check the box Use Secure LDAP Protocol if you access with LDAP over SSL
(ldaps)
3. subtree search
Searches for object at any point below the given basedn
6. (Optional) Size limit, specifies the maximum number of returned entries,
7. (Optional) Time limit, specifies the maximum number of milliseconds, the SERVER can
use for performing the search. It is NOT the maximum time the application will wait.
When a very large returnset is returned, from a very fast server, over a very slow line,
you may have to wait for ages for the completion of the search request, but this parameter
will not influence this.
8. (Optional) Attributes you want in the search answer. This can be used to limit the size of
the answer, especially when an object has very large attributes (like jpegPhoto). There are
three possibilities:
1. Leave empty (the default setting must also be empty) This will return all
attributes.
2. Put in one empty value (""), it will request a non-existent attributes, so in reality it
returns no attributes
3. Put in the attributes, separated by a semi-colon. It will return only the requested
attributes
9. (Optional) Return object. Checked will return all java-object attributes, it will add these
to the requested attributes, as specified above.
Unchecked will mean no java-object attributes will be returned.
10. (Optional) Dereference aliases. Checked will mean it will follow references, Unchecked
says it will not.
11. (Optional) Parse the search results?. Checked will mean it gets all results in response
data, Unchecked says it will not.
Take care: This single bind/unbind is in reality two separate operations but cannot easily be
split!
add
this will mean that the attribute value (not optional in this case) will be added to the
attribute.
When the attribute is not existing, it will be created and the value added
When it is existing, and defined multi-valued, the new value is added.
when it is existing, but single valued, it will fail.
replace
This will overwrite the attribute with the given new value (not optional here)
When the attribute is not existing, it will be created and the value added
When it is existing, old values are removed, the new value is added.
delete
When no value is given, all values will be removed
When a value is given, only that value will be removed
when the given value is not existing, the test will fail
this will move the complete subtree, plus all retired people in the subtree to the new place
in the tree.
In this listener, you have three tabs to view, the sampler result, the request and the response data.
1. The sampler result just contains the response time, the return code and return message
2. The request gives a short description of the request that was made, in practice no relevant
information is contained here.
3. The response data contains the full details of the sent request, as well the full details of
the received answer, this is given in a (self defined) xml-style. The full description can be
found here.
If the sampler appears to be getting an error from the webservice, double check the SOAP
message and make sure the format is correct. In particular, make sure the xmlns attributes are
exactly the same as the WSDL. If the xml namespace is different, the webservice will likely
return an error.
JMeter sends requests in the order that they appear in the tree.
Start by using menu File Templates and select template "Building a SOAP Webservice
Test Plan". Then, click "Create" button.
Next, select "HTTP Header Manager" and update "SOAPAction" header to match your
webservice. Some webservices may not use SOAPAction in this case remove it.
Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all
other webservices. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and
gSoap.
The last step is to paste the SOAP message in the "Body Data" text area.
Adding Users
The Thread Group tells JMeter the number of users you want to simulate, how often the users
should send requests, and the how many requests they should send.
Select the Thread Group element in the tree, if you have not already selected it. You should now
see the Thread Group Control Panel in the right section of the JMeter window (see Figure 9.2
below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter
JMeter Users.
In the next field, the Ramp-Up Period, leave the default value of 0 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up
Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So,
if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would
be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will
immediately start all of your users.
Finally, clear the checkbox labeled "Forever", and enter a value of 2 in the Loop Count field.
This property tells JMeter how many times to repeat your test. If you enter a loop count value of
0, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select
the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
See Figure 9.2 for the completed JMeter Users Thread Group.
Select the JMeter Users element and add a Aggregate Graph listener
(Add Listener Aggregate Graph). Next, you need to specify a directory and filename of the
output file. You can either type it into the filename field, or select the Browse button and browse
to a directory and then enter a filename.
Rest WebService
Testing a REST WebService is very similar as you only need to modify in HTTP Request
You may also need to modify "HTTP Header Manager" to select the correct "Content-Type"
Make sure the required jar files are in JMeter's lib directory. If they are not, shutdown JMeter,
copy the jar files over and restart JMeter. See Getting Started for details.
In this section, you will learn how to create a Test Plan to test a JMS Point-to-Point messaging
solution. The setup of the test is 1 threadgroup with 5 threads sending 4 messages each through a
request queue. A fixed reply queue will be used for monitoring the reply messages. To construct
the Test Plan, you will use the following elements: Thread Group, JMS Point-to-Point, and
Graph Results.
General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the
other uses queues. Topic messages are commonly known as pub/sub messaging. Topic
messaging is generally used in cases where a message is published by a producer and consumed
by multiple subscribers. A JMS sampler needs the JMS implementation jar files; for example,
from Apache ActiveMQ. See here for the list of jars provided by ActiveMQ.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the
right section of the JMeter window (see Figure 10.1 below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter Point-
to-Point.
In the next field, the Ramp-Up Period, leave set the value to 0 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up
Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So,
if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would
be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will
immediately start all of your users.
Clear the checkbox labeled "Forever", and enter a value of 4 in the Loop Count field. This
property tells JMeter how many times to repeat your test. If you enter a loop count value of 0,
then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select
the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
Select the Thread Group element and add a Graph Results listener (Add Listener Graph
Results). Next, you need to specify a directory and filename of the output file. You can either
type it into the filename field, or select the Browse button and browse to a directory and then
enter a filename.
References:
All the articles mentioned in the book are described by Author itself. Some images are taken
from http://jmeter.apache.org/ for reference.
Author wants to thank for all the support provided by Apache JMeter Organization, without there
guideline this book cant be completed.
Best regards,