jMeter Quick Guide

http://www.tuto rialspo int.co m/jme ter/jmeter_quick_g uide.htm Copyrig ht © tuto rials point.com

JMETER - QUICK GUIDE

Before digg ing into the JMeter, let us first understand few jarg ons mostly associated with the testing of any

application.

Performance Test: This test sets the ‘best possible’ performance expectation under a g iven

config uration of infrastructure. It also hig hlig hts early in the testing process if chang es need to be made

before application g oes into production.

Load Test: This test is basically used for exercising \discovering the system under the top load it was

desig ned to operate under.

Stress T est: This test is an attempt to break the system by overwhelming its resources.

What is JMeter?

JMeter is a software allowing to load test or performance oriented business (functional) test on different

protocols or technolog ies. Stefano Mazzoc c hi of the Apache Software Foundation was the orig inal

developer of JMeter. He wrote it primarily to test the performance of Apache JServ (Now called as Apache

Tomcat project). Apache later redesig ned JMeter to enhance the GUI and to add functional-testing capabilities.

This is a Java desktop application with a g raphical interface using the Swing graphical API, can therefore run on

any environment / workstation accepting a Java virtual machine, for example: Windows, Linux, Mac, etc.

The protocols supported by JMeter are:

Web: HTTP, HTTPS sites 'web 1.0' web 2.0 (ajax, flex and flex-ws-amf)

Web Services: SOAP / XML-RPC

Database via JDBC drivers

Directory: LDAP

Messag ing Oriented service via JMS

Service: POP3, IMAP, SMTP

FTP Service

JMeter Features

Following are some of the features of JMeter:

Its free. Its an open source software.

It has simple and intuitive GUI.

JMeter can load and performance test many different server types: Web - HTTP, HTTPS, SOAP,

Database via JDBC, LDAP, JMS, Mail - POP3

It is platform-independent tool. On Linux/Unix, JMeter can be invoked by clicking on JMeter shell script.

On Windows it can be invoked by starting the jmeter.bat file.

It has full Swing and lig htweig ht component support (precompiled JAR uses packages javax.swing .* ).

JMeter store its test plans in XML format. This means you can generate a test plan using a text editor.

It's full multi-threading framework allows concurrent sampling by many threads and simultaneous sampling

of different functions by separate thread g roups.

It is hig hly Extensible.

Can also be used to perform automated and functional testing of your application.

How JMeter Works?

JMeter simulates a g roup of users sending requests to a targ et server, and return statistics that show the

performance/functionality of the targ et server / application via tables, g raphs etc. The fig ure below depicts this

process:

ENVIRONMENT SET-UP

JMeter is a framework for Java, so the very first requirement is to have JDK installed in your machine.

System Requirement

J DK 1.6 or above.

Memory no minimum requirement.

Disk Space no minimum requirement.

Operating System no minimum requirement.

Step 1 - verify Java installation in your machine

Now, open console and execute the following java command.

OS Task Command

Windows Open Command Console c:\> java -version

Linux Open Command Terminal $ java -version

Mac Open Terminal machine:~ joseph$ java -version

Let's verify the output for all the operating systems:

OS Output

Windows java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)

Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Linux java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)

Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Mac java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)

Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

If you do not have Java installed, install the Java Software Development Kit (SDK) from

http://www.oracle.com/technetwork/java/javase/downloads/index.html. We are assuming Java 1.7.0_25 as

installed version for this tutorial.

Step 2: Set JAVA environment

Set the JAVA_HO ME environment variable to point to the base directory location, where Java is installed on

your machine. For example;

OS Output

Windows Set the environment variable JAVA_HOME to C:\Prog ram Files\Java\jdk1.7.0_25

Linux export JAVA_HOME=/usr/local/java-current

Mac export JAVA_HOME=/Library/Java/Home

Append Java compiler location to System Path.

OS Output

Windows Append the string ; C:\Prog ram Files\Java\jdk1.7.0_25\bin to the end of the system

variable, Path.

Linux export PATH=$PATH:$JAVA_HOME/bin/

Mac not required

Verify Java Installation using java -version command explained above.

Step 3: Download JMeter

Download latest version of JMeter from http://jmeter.apache.org /download_jmeter.cg i. At the time of writing

this tutorial, I downloaded apache-jmeter-2.9 and copied it into C:\>JMeter folder.

The directory structure should look like as below:

apache-jmeter-2.9

apache-jmeter-2.9\bin

apache-jmeter-2.9\docs

apache-jmeter-2.9\extras

apache-jmeter-2.9\lib\

apache-jmeter-2.9\lib\ext

apache-jmeter-2.9\lib\junit

apache-jmeter-2.9\printable_docs

You can rename the parent directory (i.e. apache-jmeter-2.9) if you want, but do not chang e any of the sub-

directory names.

Step 4: Run JMeter

Once the you download the JMeter, goto to the bin directory. In our case it would be

/home/manisha/apac he-jmeter-2.9/bin. Now click on the following :

OS Output

Windows jmeter.bat

Linux jmeter.sh

Mac jmeter.sh

Once clicked on the above file, after a short pause, the JMeter GUI should appear which is a Swing application as

seen in the imag e below:

This is the main pag e and default pag e of the tool.

BUILD TEST PLAN

What is a Test Plan?

A Test Plan defines and provides a layout of how and what to test for example the web application as well as the

client server application. It can be viewed as a container for running tests. A complete test plan will consist of one

or more elements such as thread g roups, log ic controllers, sample-g enerating controllers, listeners, timers,

assertions, and config uration elements. A test plan must have at least one thread g roup. We shall discuss these

elements in detail in the next chapter Test Plan Elements.

Follow the below steps to write a test plan:

Start the JMeter window

Open the JMeter window by clicking on /home/manisha/apac he-jmeter-2.9/bin/jmeter.sh. The

JMeter window will appear as below:

T his is a JMeter

window having nothing added yet. Details of the above window are:

Test Plan node is where the real test plan is kept.

Workbench node simply provides a place to temporarily store test elements while not in use, for

copy/paste purposes. When you save your test plan, WorkBench items are not saved with it.

Add/Remove Elements

Elements (which will be discussed in the next chapter Test Plan Elements) of a test plan can be added by rig ht

clicking on the Test Plan node and choosing a new element from the "add" list.

Alternatively, elements can be loaded from file and added by choosing the "merg e" or "open" option.

For example let's add a Thread Group element to a Test Plan as shown below:

To remove an element, make sure the element is selected, rig ht-click on the element, and choose the "remove"

option.

Loading and Saving Elements

To load an element from file, rig ht click on the existing tree element to which you want to add the loaded element,

and select the "merg e" option. Choose the file where your elements are saved. JMeter will merg e the elements

into the tree.

To save tree elements, rig ht click on an element and choose the Save Selection As ... option. JMeter will save the

element selected, plus all child elements beneath it. By default JMeter doesn't save the elements, you need to

explicitly save it as mentioned earlier.

Config uring Tree Elements

Any element in the Test Plan can be config ured in the controls present in JMeter's rig ht-hand frame. These

controls allow you to config ure the behavior of that particular test element. For example the Thread Group can

be config ured for number of users, ramp up period etc as below:

Saving the Test Plan

You can save an entire Test Plan either by using Save or "Save Test Plan As ..." from the File menu.

Running a Test Plan

You can run your Test Plan choosing Start (Control + r) from the Run menu item. When JMeter is running , it

shows a small g reen box at the rig ht hand end of the section just under the menu bar.

The numbers to the left of the g reen box are the number of active threads / total number of threads. These only

apply to a locally run test; they do not include any threads started on remote systems when using client-server

mode.

Stopping a Test

You can stop your test in two ways:

Using Stop (Control + '.'). T his stops the threads immediately if possible.

Using Shutdown (Control + ','). This requests the threads to stop at the end of any current work.

TEST PLAN ELEMENTS

A JMeter Test Plan comprises of test elements which are discussed below. A Test Plan would comprise at least

one Thread Group. Within each Thread Group we may place a combination of one or more of other elements:

Sampler, Log ic Controller, Config uration Element, Listener, and Timer. Each Sampler can be preceded by one

or more Pre-processor element, followed by Post-processor element, and/or Assertion element. Let's see

each of these elements in detail:

ThreadGroup

Thread Group elements are the beg inning points of your test plan. As the name sug g ests, the thread g roup

elements control the number of threads JMeter will use during the test. We can also control the following via the

Thread Group:

By setting the number of Threads.

By setting the Ramp Up Time

By setting the number of test iterations.

The Thread Group Control Panel looks like this:

Details of each component on the above panel are:

Action to be taken after a Sampler error: In case any error occurs during test execution you may

let the test either:

Continue to the next element in the test

Stop Thread to stop the current Thread.

Stop Test completely, in case you want to inspect the error before continue running .

Number of T hreads: Simulates the number of user(s) or connection(s) to your server application.

Ramp-Up Period: Defines how long it will take JMeter to g et all threads running .

Loop Count: Defines the number of times to execute the test.

Scheduler checkbox Once selected, the Scheduler Config uration section will appear at the bottom of

the control panel.

Scheduler Config uration You can config ure the start and end time of running the test.

Controllers

JMeter has two types of Controllers: Samplers and Logic Controllers.

Samplers

Samplers allow JMeter to send specific types of requests to a server. They simulate a user's request for a pag e

from the targ et server. For example, you can add a HTTP Request sampler if you need to perform a POST,

GET, DELETE on a HTT P service

Some useful samplers are:

HTTP Request

FTP Request

JDBC Request

Java Request

SOAP/XML Request

RPC Requests

An HTTP Request Sampler Control Panel looks like the following fig ure:

Log ic Controllers

Log ic Controllers let you control order of processing of Samplers in a Thread. Log ic Controllers can chang e the

order of request coming from any of their child elements. Some examples are: ForEach Controller, While

Controller, Loop Controller, IF Controller, Run Time Controller, Interleave Controller, Throug hput Controller,

Run Once Controller.

A Loop Controller Control Panel looks like the following fig ure:

The following list consists of all the Log ic Controllers JMeter provides:

Simple Controller

Loop Controller

Once Only Controller

Interleave Controller

Random Controller

Random Order Controller

Throug hput Controller

Runtime Controller

If Controller

While Controller

Switch Controller

ForEach Controller

Module Controller

Include Controller

Transaction Controller

Recording Controller

Test Frag ments

Test Frag ments is a special type of element placed at the same level as Thread Group element. It is

disting uished from a Thread Group in that it is not executed unless it is referenced by either a Module Controller

or an Include_Controller. This element is purely for code re-use within Test Plans.

Listeners

Listeners let you view the results of Samplers in the form of tables, g raphs, trees or simple text in some log files.

They provide visual access to the data g athered by JMeter about the test cases as a Sampler component of

JMeter is executed.

Listeners can be added anywhere in the test, including directly under the test plan. They will collect data only

from elements at or below their level. The following list consists of all the Listeners JMeter provides:

Sample Result Save Config uration

Graph Full Results

Graph Results

Spline Visualizer

Assertion Results

View Results Tree

Agg reg ate Report

View Results in Table

Simple Data Writer

Monitor Results

Distribution Graph (alpha)

Agg reg ate Graph

Mailer Visualizer

BeanShell Listener

Summary Report

Timers

By default, a JMeter thread will send requests without pausing between each sampler. This may not be what you

want. We can add a timer element which will allow us to define a period to wait between each request.

The following list consists of all the Timers JMeter provides:

Constant Timer

Gaussian Random Timer

Uniform Random Timer

Constant Throug hput T imer

Synchronizing T imer

JSR223 Time

BeanShell Time

BSF Time

Poisson Random T ime

As an example, the Constant Timer Control Panel looks like this:

Assertions

Assertions allow you to include some validation test on the response of your request made using a Sampler.

Using assertions you can prove that your application is returning the correct data. JMeter will hig hlig ht when an

assertion fails.

The following list consists of all the Assertions JMeter provides:

Beanshell Assertion

BSF Assertion

Compare Assertion

JSR223 Assertion

Response Assertion

Duration Assertion

Size Assertion

XML Assertion

BeanShell Assertion

MD5Hex Assertion

HTML Assertion

XPath Assertion

XML Schema Assertion

As an example, the Response Assertion Control Panel looks like this:

Config uration Elements

Config uration Elements allow you to create defaults and variables to be used by Samplers. They are used to add

or modify requests made by Samplers.

They are executed at the start of the scope of which they are part, before any Samplers that are located in the

same scope. Therefore, a Config uration Element is accessed only from inside the branch where it is placed.

The following list consists of all the Config uration Elements JMeter provides:

Counter

CSV Data Set Config

FTP Request Defaults

HTTP Authorization Manag er

HTTP Cache Manag er

HTTP Cookie Manag er

HTTP Proxy Server

HTTP Request Defaults

HTTP Header Manag er

Java Request Defaults

Keystore Config uration

JDBC Connection Config uration

LDAP Request Defaults

LDAP Extended Request Defaults

TCP Sampler Config

User Defined Variables

Simple Config Element

Random Variable

Pre-Processor Elements

A Pre-Procesor is something that will happen before a sampler executes. They are often used to modify the

setting s of a Sample Request just before it runs, or to update variables that are not extracted from response

text.

The following list consists of all the Pre-Processor Elements JMeter provides:

HTML Link Parser

HTTP URL Re-writing Modifier

HTTP User Parameter Modifier

User Parameters

JDBC PreProcessor

JSR223 PreProcessor

Reg Ex User Parameters

BeanShell PreProcessor

BSF PreProcessor

Post-Processor Elements

A Post Processor executes after a sampler finishes its execution. This element is most often used to process the

response data, for example, to retrieve particular value for later use.

The following list consists of all the Post-Processor Elements JMeter provides:

Reg ular Expression Extractor

XPath Extractor

Result Status Action Handler

JSR223 PostProcessor

JDBC PostProcessor

BSF PostProcessor

CSS/JQuery Extractor

BeanShell PostProcessor

Debug PostProcessor

Execution order of Test Elements

Following is the execution order of the test plan elements:

1. Config uration elements

2. Pre-Processors

3. Timers

4. Sampler

5. Post-Processors (unless SampleResult is null)

6. Assertions (unless SampleResult is null)

7. Listeners (unless SampleResult is null)

WEB TEST PLAN

Let's build a simple test plan which tests a web pag e. We will write a test plan in Apache JMeter so that we can

test performance of one web pag e say pag e shown by the URL:http://www.tutorialspoint.com/.

Start JMeter

Open the JMeter window by clicking on /home/manisha/apac he-jmeter-2.9/bin/jmeter.sh. The

JMeter window will appear as below:

T his is a JMeter

window having nothing added yet. Details of the above window are:

Test Plan node is where the real test plan is kept.

Workbench node is where the temporary stuff is kept.

Rename Test Plan

Chang e the name of test plan node to Sample T est in the Name text box. You have to chang e focus to workbench

node and back to Test Plan node to see the name g etting reflected.

Add Thread Group

Now we will add our first element in the window. We will add one Thread Group, which is placeholder for all other

elements like Samplers, Controllers, Listeners. We need one so we can config ure number of users to simulate.

In JMeter all the node elements are added by using the context menu. You have to rig ht click the element where

you want to add a child element node. Then choose the appropriate option to add.

Rig ht click on Sample Test(our Test Plan )> Add> Threads(Users)> Thread Group. Thread Group will get

added under the Test Plan (Sample Test) node.

We will name Thread Group as Users. For us this element means Users visiting the TutorialsPoint Home Pag e.

Add Sampler

Now we have to add one Sampler in our T hread Group (Users). As done earlier for adding Thread g roup, this

time we will open the context menu of the Thread Group (Users) node by rig ht clicking and we will add HTTP

Request Sampler by choosing Add > Sampler> HTTP request option.

This will add one empty HTTP Request Sampler under the Thread Group (Users) node. Let us config ure this

node element:

Name: We will chang e the name to reflect the action what we want to achieve. We will name it as Visit

TutorialsPoint Home Page

Server Name or IP: Here we have to type the web server name. In our case it is

www.tutorialspoint.c om. (http:// part is not written this is only the name of the server or its IP)

Protocol: We will keep this blank, which means we want HTTP as the protocol.

Path: We will type path as / (slash). This means we want the root pag e of the server.

Add Listener

We will add a listener. Let us add View Results Tree Listener under the Thread Group (User) node. This will

ensure that the results of the Sampler will be available to view in this Listener node element. Open the context

menu and Rig ht click on Thread Group(Users) choose Add > Listener > View Results Tree option to add the

listener.

Run the Test Plan

Now with all the setup, let's execute the test plan. With the config uration of the Thread Group (Users) we have

kept it all default values. This means JMeter will execute the sampler only once. It will be like a sing le user and

only one time.

This is similar to like a user visiting a web pag e throug h browser, only here we are doing that throug h JMeter

sampler. We will execute the test plan using Run > Start option.

Apache JMeter asks us to save the test plan in a disk file before actually starting the test. This is important if we

want to run the test plan ag ain and ag ain. If we say not to save by clicking No option it will run without saving .

View Output

We have kept the setting of the thread g roup as sing le thread (that means one user only) and loop for 1 time (that

means run only one time), hence we will g et result of one sing le transaction in the View Result Tree Listener.

Details of the above result are:

Green color ag ainst the name Visit TutorialsPoint Home Page indicates success.

JMeter has stored all the headers and the response sent by the web server and ready to show us the

result in many ways.

The first tab is Sampler Results. It shows JMeter data as well as data returned by the web server.

The second tab is Request, where all the data which was sent to the web server as part of the request is

shown.

The last tab is Response data. In this tab the listener shows the data received from server as it is in text

format.

This is just a simple test plan which executes only one request. But JMeter's real streng th is in sending the same

request like many users are sending it. To test the web servers with multiple users we will have to chang e the

Thread Group (Users) setting s.

DATABASE TEST PLAN

In this chapter we will see how to create a simple test plan to test the database server. For our test purpose we

have used the MYSQL database server. You can use any other database for testing . For installation and table

creation in MYSQ please refer MYSQL Tutorial.

Once MYSQL is installed, follow the steps below to setup the database:

Create a database with name "tutorial".

Create a table tutorials_tbl.

Insert records into tutorials_tbl :

mysql> use TUTORIALS;

Database changed

mysql> INSERT INTO tutorials_tbl

->(tutorial_title, tutorial_author, submission_date)

->VALUES

->("Learn PHP", "John Poul", NOW());

Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO tutorials_tbl

->(tutorial_title, tutorial_author, submission_date)

->VALUES

->("Learn MySQL", "Abdul S", NOW());

Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO tutorials_tbl

->(tutorial_title, tutorial_author, submission_date)

->VALUES

->("JAVA Tutorial", "Sanjay", '2007-05-06');

Query OK, 1 row affected (0.01 sec)

mysql>

Copy the appropriate JDBC driver to /home/manisha/apache-jmeter-2.9/lib.

Create JMeter Test Plan

First let's start the JMeter from /home/manisha/apac he-jmeter-2.9/bin/jmeter.sh.

Add Users

Now create a Thread g roup, rig ht click on Test Plan > Add> Threads(Users)> Thread Group. Thread

Group will g et added under the Test Plan node. Rename this Thread Group as JDBC Users.

We will not chang e the default properties of the Thread Group.

Adding JDBC Requests

Now that we have defined our users, it is time to define the tasks that they will be performing . In this section, you

will specify the JDBC requests to perform. Rig ht click on the JDBC Users element, select Add > Config

Element > J DBC Connection Config uration.

Set up the following fields (we are using MySQL database called tutorial):

Variable name bound to pool. This needs to uniquely identify the config uration. It is used by the JDBC

Sampler to identify the config uration to be used. We have named it as test

Database URL: jdbc:mysql://localhost:3306/tutorial

JDBC Driver class: com.mysql.jdbc.Driver

Username: root

Password: password for root

The other fields on the screen can be left as the defaults as shown below:

Now add a JDBC Request which refers to the JDBC Config uration pool defined above. Select JDBC Users

element, click your rig ht mouse button to g et the Add menu, and then select Add > Sampler > J DBC

Request. Then, select this new element to view its Control Panel. Edit the properties as below:

Variable name bound to pool. This needs to uniquely identify the config uration. It is used by the JDBC

Sampler to identify the config uration to be used. We have named it as test

Name: Learn

Enter the Pool Name: test (same as in the config uration element)

Query Type: Select statement

Enter the SQL Query String field.

Create Listener

Now add the Listener element. This element is responsible for storing all of the results of your JDBC requests in

a file and presenting a visual model of the data.

Select the JDBC Users element and add a View Results Tree listener (Add > Listener > View Results

Tree).

Save and Execute Test Plan

Now save the above test plan as db_test.jmx. Execute this test plan using Run > Start option.

Verify Output

In the last imag e you can see that 2 records are selected.

FTP TEST PLAN

In this chapter we will see how to test a FTP site using JMeter. Let us create a Test Plan to test the FTP site.

Rename Test Plan

Start the JMeter window by clicking on /home/manisha/apache-jmeter-2.9/bin/jmeter.sh. Click on the

Test Plan node. Rename this Test Plan node as TestFTPSite.

Add Thread Group

Add one Thread Group, which is placeholder for all other elements like Samplers, Controllers, Listeners. Rig ht

click on TestFTPSite(our T est Plan) > Add > Threads(Users) > Thread Group. Thread Group will

g et added under the T est Plan (TestFTPSite) node.

Next let us modify the default properties of the Thread Group to suit our testing . Following properties are

chang ed:

Name: FTPusers

Number of T hreads (Users): 4

Ramp-Up Period: leave the the default value of 0 seconds.

Loop Count:1

Add Sampler- FTP Request

Now that we have defined our users, it is time to define the tasks that they will be performing . We will add FTP

Request elements. We will add two FTP request elements, one which will retrieve a file and one which will put a

file on the ftp site. Beg in by selecting the FTPusers element. Click your rig ht mouse button to g et the Add menu,

and then select Add > Sampler > FTP Request. Then, select the FTP Request element in the tree and edit

the following properties as in the imag e below:

The following details are entered in the this element:

Name: FTP Request Get

Server Name or IP: 184.168.74.29

Remote File: /home/manisha/sample_ftp.txt

Loc al File:sample_ftp.txt

Select g et(RETR)

Username:manisha

Password:manisha123

Now add another FTP request as above and edit the properties as in the imag e below:

The following details are entered in the this element:

Name: FTP Request Put

Server Name or IP: 184.168.74.29

Remote File: /home/manisha/examplefile.txt

Loc al File: /home/manisha/work/examplefile.txt

Select put(STOR)

Username:manisha

Password:manisha123

Add Listener

The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of

the results of your FTP requests in a file and presenting a visual model of the data.

Select the FTPusers element and add a View Results Tree listener (Add > Listener > View Results

Tree).

Run the Test Plan

Now save the above test plan as ftpsite_test.jmx. Execute this test plan using Run > Start option.

View Output

The following output can be seen in the listener.

You can see that four requests are made for each FTP request. We see that the test is successful. The retrieved

file for GET request is stored in the bin folder. In our case it would be /home/manisha/apache-jmeter-

2.9/bin/. For PUT request the file is uploaded at the path /home/manisha/.

WEBSERVICE TEST PLAN

In this chapter, we will learn how to create a Test Plan to test a WebService. For our test purpose, we have

created a simple webservice project and deployed it on the Tomcat server locally.

Create Webservice Project

To create a webservice project we have used Eclipse IDE. First write the Service Endpoint Interface

HelloWorld under the packag e c om.tutorialspoint.ws. The contents of the HelloWorld.java are as below:

package com.tutorialspoint.ws;

import javax.jws.WebMethod;

import javax.jws.WebService;

import javax.jws.soap.SOAPBinding;

import javax.jws.soap.SOAPBinding.Style;

//Service Endpoint Interface

@WebService

@SOAPBinding(style = Style.RPC)

public interface HelloWorld{

@WebMethod String getHelloWorldMessage(String string);

}

This service has a method g etHelloWorldMessag e which takes String paramater.

Next create the implementation class HelloWorldImpl.java under the packag e com.tutorialspoint.ws.

package com.tutorialspoint.ws;

import javax.jws.WebService;

@WebService(endpointInterface="com.tutorialspoint.ws.HelloWorld")

public class HelloWorldImpl implements HelloWorld {

@Override

public String getHelloWorldMessage(String myName){

return("Hello "+myName+" to JAX WS world");

}

As a next step let's publish this web service locally by creating the Endpoint publisher and expose the service on

the server.

The publish method takes two parameters:

Endpoint URL String .

Implementor object, in this case the HelloWorld implementation class, which is exposed as a Web service

at the endpoint identified by the URL mentioned in the parameter above.

The contents of HelloWorldPublisher.java is a follows :

package com.tutorialspoint.endpoint;

import javax.xml.ws.Endpoint;

import com.tutorialspoint.ws.HelloWorldImpl;

public class HelloWorldPublisher {

public static void main(String[] args){

Endpoint.publish("http://localhost:9000/ws/hello", new HelloWorldImpl());

}

Next modify the web.xml as below:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems,

Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

<web-app>

<listener-class>

com.sun.xml.ws.transport.http.servlet.WSServletContextListener

</listener-class>

</listener>

<servlet-name>hello</servlet-name>

<servlet-class>

com.sun.xml.ws.transport.http.servlet.WSServlet

</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>hello</servlet-name>

<url-pattern>/hello</url-pattern>

</servlet-mapping>

<session-config>

<session-timeout>120</session-timeout>

</session-config>

</web-app>

To deploy this application as webservice we would need another config uration file sun-jaxws.xml, the contents

of this file are as below:

<?xml version="1.0" encoding="UTF-8"?>

<endpoints

xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"

version="2.0">

<endpoint

name="HelloWorld"

implementation="com.tutorialspoint.ws.HelloWorldImpl"

url-pattern="/hello"/>

</endpoints>

Now that all the files are ready the directory structure would look like as in the imag e below:

Now create a WAR file of this application. Choose the projec t > rig ht c lic k > Export > WAR file. Save

this as hello.war file under the webapps folder of Tomcat server. Now start the Tomcat server. Once the

server is started, you should be able to access the webservice with the following URL:

http://localhost:8080/hello/hello

Create JMeter Test plan

Now let's create a test plan to test the above webservice.

Rename Test Plan

Start the JMeter window by clicking on /home/manisha/apache-jmeter-2.9/bin/jmeter.sh. Click on the

Test Plan node. Rename this Test Plan node as Webservic eTest.

Add Thread Group

Add one Thread Group, which is placeholder for all other elements like Samplers, Controllers, Listeners. Rig ht

click on WebserviceTest(our Test Plan) > Add > Threads(Users) > Thread Group. Thread

Group will g et added under the Test Plan (WebserviceTest) node.

Next let us modify the default properties of the Thread Group to suit our testing . Following properties are

chang ed:

Name: webservice user

Number of T hreads (Users): 2

Ramp-Up Period: leave the the default value of 0 seconds.

Loop Count:2

Add Sampler-SOAP/XML -RPC Request

Now that we have defined our users, it is time to define the tasks that they will be performing . We will add

SOAP/XML-RPC Request element. Click your rig ht mouse button to g et the Add menu, and then select Add >

Sampler > SOAP/XML-RPC Request. Then, select the SOAP/XML-RPC Request element in the tree

and edit the following properties as in the imag e below:

The following details are entered in the this element:

Name: SOAP/XML-RPC Request

URL: http://localhost:8080/hello/hello?wsdl

Soap/XML-RPC Data: Enter the below contents

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:web="http://ws.tutorialspoint.com/">

<soapenv:Header/>

<soapenv:Body>

<web:getHelloWorldMessage>

<arg0>Manisha</arg0>

</web:getHelloWorldMessage>

</soapenv:Body>

</soapenv:Envelope>

Add Listener

The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of

the results of your HTTP requests in a file and presenting a visual model of the data.

Select the webservice user element and add a View Results Tree listener (Add > Listener > View Results

Tree).

Run the Test Plan

Now save the above test plan as test_webservice.jmx. Execute this test plan using Run > Start option.

View Output

The following output can be seen in the listener.

In the last imag e you can see the response messag e "Hello Manisha to JAX WS world".

JMS TEST PLAN

In this chapter we will learn how to write a simple test plan to test JMS (Java Messag ing Service). Those who are

not aware of JMS please make yourself familiar with JMS before reading this chapter. JMS supports two types

of messag ing :

Point-to-Point messag ing : Queue messag ing is g enerally used for transactions where the sender

expects a response. Messag ing systems are quite different from normal HTTP requests. In HTTP, a

sing le user sends a request and g ets a response.

Topic messag ing : Topic messag es are commonly known as pub/sub messag ing . Topic messag ing is

g enerally used in cases where a messag e is published by a producer and consumed by multiple

subscribers.

Let us see a test example for each of these. Pre-requisites for testing JMS are:

We will be using Apache ActiveMQ for our example. Thoug h there are other JMS servers like IBM

WebSphere MQ (formerly MQSeries), Tibco, etc. Download the binaries from the Apache ActiveMQ

website.

Unzip the archive, go to the decompressed directory and run the following command from the command

console to start the ActiveMQ server:

.\bin\activemq start

You can verify if the ActiveMQ server has started by visiting the admin interface at the following address

http://localhost:8161/admin/. If it asks for authentication enter the userid and password as admin. The

screen would be similar as below:

Now copy the activemq-all-x.x.x.jar (XXX depending on the version) from the ActiveMQ unzipped

directory to /home/manisha/apac he-jmeter-2.9/lib.

With the above setup let's build the test plan for:

JMS Point-to-Point Test Plan

JMS Topic Test Plan

MONITOR TEST PLAN

In this chapter we will discuss about how to create Test plan using JMeter, to monitor webservers. Uses of

monitor tests are:

Monitors are useful for a stress testing and system manag ement.

Used with stress testing , the monitor provides additional information about server performance.

Monitors makes it easier to see the relationship between server performance and response time on the

client side.

As a system administration tool, the monitor provides an easy way to monitor multiple servers from one

console.

We would need Tomcat 5 or above version for monitoring . For our test purpose we will monitor Tomcat 7.0.42

server. You can test any servlet container that supports JMX (Java Manag ement Extension). Let us write a test

case to monitor the Tomcat server. But before that let us first set up our tomcat server.

Setup Tomcat Server

We'll start with "open" the Tomcat service status. To do this,edit the config uration file for users

<T O MCAT_HO ME>/c onf/tomc at-users.xml. This file contains a tomcat-users section (commented)

like this:

<tomcat-users>

<!--

-->

</tomcat-users>

We need to chang e this section to add the admin roles, manag er, manag er-g ui and assig n the user "admin". The

revised file is as follows:

<tomcat-users>

<user username="admin" password="admin" roles="manager-gui,manager-script,manager-

jmx,manager-status"/>

</tomcat-users>

Now start the tomcat server <TOMCAT_HOME>/bin/startup.sh for linux and

<TOMCAT_HOME>/bin/startup.bat for windows. Once started, check that the Tomcat supervision works by

entering the below link in your browser:

http://localhost:8080/manager/status?XML=true

An authentication window appears in the browser, enter the tomcat log in and password associated (in our case it

is admin). Then, the browser shows the execution status of Tomcat as below:

From the above imag e we can note few thing s:

In the URL, note that XML = true (note the case sensitivity) allows a clean display of the supervisory

Tomcat necessary for the JMeter functioning .

Also note that there are default two connectors. The AJP connector used in g eneral coupled with the

mod_jk Apache HTTPD front module and the HTTP connector which is commonly used connector for

direct access to Tomcat via port 8080.

Write JMeter Test Plan

Let us monitor the Tomcat server by writing a test plan as below:

Rename Test Plan

Start the JMeter window by clicking on /home/manisha/apache-jmeter-2.9/bin/jmeter.sh. Click on the

Test Plan node. Add a thread g roup as explained in the next step.

Add Thread Group

Add one Thread Group. Rig ht click on Test Plan > Add > Threads(Users) > Thread Group. Thread

Group will g et added under the Test Plan node. Chang e the loop count to forever (or some larg e number) so that

enoug h samples are g enerated.

HTTP Authorization Manag er

Add the HTTP Authorization Manag er to the Thread Group element Add > Config element > HTTP

Authorization Manag er. This element manag es authentication requested by the browser to see the Tomcat

server status. Select the HTTP Authorization Manag er and edit the following details:

Username : admin (depending on the config uration in tomcat-users.xml file)

Password : admin (depending on the config uration in the tomcat-users.xml file)

The other fields are left empty.

Add Sampler-HTTP Request

Now that we have defined our users, it is time to define the tasks that they will be performing . We will add HTTP

Request element. Click your rig ht mouse button to g et the Add menu, and then select Add > Sampler >

HT T P Request. Then, select the HTTP Request element in the tree and edit the following properties as in the

imag e below:

The following details are entered in the this element:

Name : Server Status

Server Name or IP : localhost

Port : 8080

Path : /manag er/status

Parameters : Add a request parameter named "XML" in uppercase. Give it a value of "true" in

lowercase.

Optional Tasks : Check "Use as Monitor" at the bottom of the sampler.

Add Constant Timer

To request the status of the server periodically, add an element Constant Timer which will allow a time interval

between each request. Add a timer to this thread g roup Add > Timer > Constant T imer.

Enter 5000 milliseconds in the Thread Delay box. In g eneral, using intervals shorter than 5 seconds will add

stress to your server. Find out what is an acceptable interval before you deploy the monitor in your production

environment.

Add Listener

The final element you need to add to your Test Plan is a Listener. We will two types of listeners. One that stores

results in a file and second that shows the g raphical view of the results.

Select the thread g roup element and add a Simple Data Writer listener Add > Listener > Simple Data

Writer. Next, specify a directory and filename of the output file (in our case it is

/home/manisha/work/sample.csv)

Let us add another listener, by selecting the test plan element Add > Listener > Monitor Results.

Run the Test Plan

Now save the above test plan as monitor_test.jmx. Execute this test plan using Run > Start option.

View Output

Results will be saved in /home/manisha/work/sample.csv file. You can also see a g raphical result in the Monitor

result listener as in the imag e below.

Note the g raph has captions on both sides of the g raph. On the left is percent and the rig ht is dead/healthy. If the

memory line spikes up and down rapidly, it could indicate memory thrashing . In those situations, it is a g ood idea

to profile the application with Borland OptimizeIt or JProbe. What you want to see is a reg ular pattern for load,

memory and threads. Any erratic behavior usually indicates poor performance or a bug of some sort.

LISTENERS

Listeners provide access to the information JMeter g athers about the test cases while JMeter runs. The results

or information gathered by listeners can be shown in the form of:

tree

tables

g raphs

log file

All listeners write the same raw data to the output file when one is specified.

Default Config uration

The default items to be saved can be defined:

in the jmeter.properties (or user.properties) file. T his file is present in the /bin folder of JMeter.To

chang e the default format, find the following line in jmeter.properties:

jmeter.save.saveservice.output_format=

or by using the Config popup as shown in the imag e below:

JMeter creates results of a test run as JTL (JMeter Text Log s). These are normally called JTL files, as that is

the default extension - but any extension can be used.

If multiple tests are run using the same output file name, then JMeter automatically appends new data to the end

of the file.

The listener can record results to a file but not to the UI. It is meant to provide an efficient means of recording

data by eliminating GUI overhead.

When running in:

GUI mode: use the listener Simple Data Writer

non-GUI mode: the -l flag can be used to create a data file.

Listeners can use a lot of memory if there are a lot of samples. To minimise the amount of memory needed, use

the Simple Data Writer, and use the CSV format.

CSV Log format

The CSV log format depends on which data items are selected in the config uration. Only the specified data items

are recorded in the file. T he order of appearance of columns is fixed, and is as follows:

Field Description Value Example

timeStamp in milliseconds since 1/1/1970 1354223881017

elapsed in milliseconds 1858

label sampler label HTTP Request

responseCode e.g . 200, 404 200

responseMessag e e.g . OK OK

threadName Thread Group 1-1

dataType e.g . text text

success true or false true

failureMessag e if any

bytes number of bytes in the sample 34908

g rpThreads number of active threads in this thread g roup 1

allThreads total number of active threads in all g roups 1

URL http://tutorialspoint.com

Filename if Save Response to File was used

latency time to first response 132

encoding utf-8

SampleCount number of samples (1, unless multiple samples are

ag g reg ated)

ErrorCount number of errors (0 or 1, unless multiple samples are

ag g reg ated)

Hostname where the sample was g enerated LaptopManisha

IdleTime number of milliseconds of 'Idle' time (normally 0)

Variables if specified

Saving response data

The response data can be saved in the XML log file if required. But it has constraints, when the file is larg e and

also imag es cannot be included. In such cases use the Post-Processor Save_Responses_to_a_file . This

g enerates a new file for each sample, and saves the file name with the sample. The file name can then be included

in the sample log output. The data will be retrieved from the file if necessary when the sample log file is reloaded.

Loading (reading ) response data

To view an existing results file, you can use the File "Browse..." button to select a file. If necessary, just create a

dummy testplan with the appropriate Listener in it.

Saving Listener GUI data

JMeter is capable of saving any listener as a PNG file. To do so, select the listener in the left panel,

Edit > Save As Imag e.

A file dialog will appear. Enter the desired name and save the listener.

FUNCTIONS

JMeter Functions and User Variables

JMeter functions are special values that can populate fields of any Sampler or other element in a test tree.

A function call looks like this:

${__functionName(var1,var2,var3)}

_functionName matches the name of a function. For example ${__threadNum}.

If a function parameter contains a comma, then be sure to escape this with "\" as shown below.

${__time(EEE\, d MMM yyyy)}

Variables are referenced as:

${VARIABLE}

List of Functions

Following table lists a g roup of functions loosely g rouped into types:

Type of func tion Name Comment

Information threadNum g et thread number

Information samplerName g et the sampler name (label)

Information machineIP g et the local machine IP address

Information machineName g et the local machine name

Information time return current time in various formats

Information log log (or display) a messag e (and return the value)

Information log n log (or display) a messag e (empty return value)

Input String FromFile read a line from a file

Input FileToString read an entire file

Input CSVRead read from CSV delimited file

Input XPath Use an XPath expression to read from a file

Calculation counter g enerate an incrementing number

Calculation intSum add int numbers

Calculation long Sum add long numbers

Calculation Random g enerate a random number

Calculation RandomString g enerate a random string

Calculation UUID g enerate a random type 4 UUID

Scripting BeanShell run a BeanShell script

Scripting javaScript process JavaScript (Mozilla Rhino)

Scripting jexl, jexl2 evaluate a Commons Jexl expression

Properties property read a property

Properties P read a property (shorthand method)

Properties setProperty set a JMeter property

Variables split Split a string into variables

Variables V evaluate a variable name

Variables eval evaluate a variable expression

Variables evalVar evaluate an expression stored in a variable

String reg exFunction parse previous response using a reg ular expression

String escapeOroReg expChars quote meta chars used by ORO reg ular expression

String char g enerate Unicode char values from a list of numbers

String unescape Process string s containing Java escapes (e.g . \n & \t)

String unescapeHtml Decode HTML-encoded string s

String escapeHtml Encode string s using HTML encoding

String TestPlanName Return name of current test plan

There are two kinds of functions:

user-defined static values (or variables)

built-in functions

User-defined static values allow the user to define variables to be replaced with their static value when a

test tree is compiled and submitted to be run.

Note that variables cannot currently be nested; i.e ${Var${N}} does not work.

The __V (variable) function (versions after 2.2) can be used to do this: ${__V(Var${N})}.

This type of replacement is possible without functions, but was less convenient and less intuitive

Where can functions and variables be used?

Functions and variables can be written into any field of any test component.

The following functions should work OK on the test plan:

intSum

long Sum

machineName

BeanShell

javaScript

jexl

random

time

property functions

log functions

Functions which are used on the Test Plan have some restrictions. JMeter thread variables will

have not been fully set up when the functions are processed, so variable names passed as

parameters will not be set up, and variable references will not work, so split() and regex() and

the variable evaluation functions won't work. The threadNum() function won't work (and

does not make sense at test plan level).

Referencing variables and functions

Referencing a variable in a test element is done by bracketing the variable name with '${' and '}'.

Functions are referenced in the same manner, but by convention, the names of functions beg in with "__" to

avoid conflict with user value names.

Some functions take arg uments to config ure them, and these g o in parentheses, comma-delimited. If the

function takes no arg uments, the parentheses can be omitted. For eg :

${__BeanShell(vars.put("name"\,"value"))}

Alternatively, you can define your script as a variable, e.g . on the Test Plan:

SCRIPT vars.put("name","value")

The script can then be referenced as follows:

${__BeanShell(${SCRIPT})}

The Function Helper Dialog

The Function Helper Dialog is available from JMeter's Options tab.

Using the Function Helper, you can select a function from the pull down, and assig n values for its

arg uments. The left column in the table provides a brief description of the arg ument, and the rig ht column

is where you write in the value for that arg ument. Different functions take different arg uments.

Once you have done this, click the “Generate" button, and the appropriate string is g enerated for you to

copy-paste into your test plan wherever you like.

Pre-defined Variables

Some variables are defined internally by JMeter. They are:

COOKIE_cookiename - contains the cookie value

JMeterThread.last_sample_ok - whether or not the last sample was OK - true/false. Note: this is updated

after PostProcessors and Assertions have been run.

START variables

Pre-defined Properties

Some built-in properties are defined by JMeter. These are listed below. For convenience, the START

properties are also copied to variables with the same names.

START.MS - JMeter start time in milliseconds

START.YMD - JMeter start time as yyyyMMdd

START.HMS - JMeter start time as HHmmss

TESTSTART.MS - test start time in milliseconds

Please note that the START variables / properties represent JMeter startup time, not the test start time. They

are mainly intended for use in file names etc.

REGULAR EXPRESSIONS

Reg ular expressions are used to search and manipulate text, based on patterns. JMeter interprets forms of

reg ular expressions or patterns being used throug hout a JMeter test plan, by including the pattern matching

software Apache Jakarta ORO.

With the use of reg ular expressions, we can certainly save a lot of time and achieve g reater flexibility as we

create or enhance a Test Plan. Reg ular expressions provide a simple method to get information from pag es

when it is impossible or very hard to predict an outcome.

A standard usag e example of using expressions is to g et a session ID from the server response. If the server

returns a unique session key we can easily g et it using expressions in our load script.

To use reg ular expressions in your test plan, you need to use the Reg ular Expression Extractor in JMeter. You

can place reg ular expressions in any component in a Test Plan.

It is worth stressing the difference between contains and matc hes, as used on the Response Assertion test

element:

contains means that the reg ular expression matched at least some part of the targ et, so 'alphabet'

"contains" 'ph.b.' because the reg ular expression matches the substring 'phabe'.

matches means that the reg ular expression matched the whole targ et. So 'alphabet' is "matched" by

'al.*t'.

Suppose you want to match the following portion of a web-pag e:

name="file" value="readme.txt"

and you want to extract readme.txt. A suitable reg ular expression would be:

name="file" value="(.+?)">

The special characters above are:

( and ) - these enclose the portion of the match string to be returned

. - match any character

+ - one or more times

? - stop when first match succeeds

Create JMeter Test Plan

Let us understand the use of Reg ular expressions in the Reg ular Expression Extractor—a Post-Processor

Element by writing a test plan. This element will extract text from the current pag e using a Reg ular Expression to

identify the text pattern that a desired element conforms with.

First we will write an HTML pag e which a list of people and their email id's. Deploy it to our tomcat server. The

contents of html (index.html) are as follows:

<html>

<head>

</head>

<body>

<th style="border: 1px solid #000000;">ID</th><th style="border: 1px solid

#000000;">name</th><th style="border: 1px solid #000000;">Email</th>

<tr><td >manisha@domain.com</td></tr>

<tr><td >joe@domain.com</td></tr>

</table>

</body>

</html>

On deploying it on tomcat server, this pag e would look like as in the snapshot below:

In our test plan we will select the person in the first row of the person table seen in the person list pag e above. To

capture the ID of this person, let us first determine the pattern where we will find the person in the second row.

As can be seen in the following snapshot, the ID of the second person is surrounded by <td > and </td >, and it is

the second row of data having this pattern. We can use this to match the exact pattern that we want to extract

information from. As we want to extract two pieces of information from this pag e, the person ID and the person's

name, the fields are defined as follows:

Start JMeter, add a Thread g roup Test Plan > Add> Threads(Users)> Thread Group.

Next add a sampler HTTP Request, select the test plan rig ht click Add > Sampler > HTTP Request and

enter the details as below:

Name: Manag e

Server Name or IP: localhost

Port Number: 8080

Protocol: We will keep this blank, which means we want HTTP as the protocol.

Path: jmeter/index.html

Next, add a Reg ular Expression Extractor. Select the HTTP Request Sampler (Manag e), rig ht click Add >

Post Processor > Reg ular Expression Extrac tor.

Details of the above snapshot are as below:

Field Description

Reference

Name

The name of the variable in which the extracted test will be stored (refname).

Reg ular

Expression

The pattern ag ainst which the text to be extracted will be matched. The text g roups that will

extracted are enclosed by the characters '(' and ')'. We use '.+?' to indicate a sing le instance of

the text enclosed by the <td..>..</td> tag s. In our example the expression is : <td

>(+?)</td>\s*

Template Each g roup of text extracted will be placed as a member of the variable Person, following the

order of each g roup of pattern enclosed by '(' and ')'. Each g roup is stored as refname_g #,

where refname is the string you entered as the reference name, and # is the g roup number.

$1$ to refers to g roup 1, $2$ to refers to g roup 2, etc. $0$ refers to whatever the entire

expression matches. In this example, the ID we extract will be maintained in Person_g 1, while

the Name value will be stored in Person_g 2.

Match No. Since we plan to extract only the second occurrence of this pattern, matching the second

volunteer, we use value 2. Value 0 would make a random matching , while a neg ative value

needs to be used with the ForEach Controller.

Default If the item is not found, this will be the default value. This is an optional field. You may leave it

blank.

Add a listener to capture the result of this Test Plan. Rig ht click on Thread Group choose Add > Listener >

View Results Tree option to add the listener.

Save the test plan as reg_express_test.jmx and run the test. The output would be a success as in the snapshot

below:

BEST PRACTICES

JMeter has some limitations especially when it is run in a distributed environment. Following these guidelines will

assist in creating a real and continuous load:

Use multiple instances of JMeter in case the number of threads are more.

Check the Scoping Rules and desig n according ly.

Use naming conventions always for all elements.

Check the default browser Connectivity setting s, before executing scripts.

Add Listeners appropriately.

Below are some sug g estion to reduce resource requirements:

Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl.

Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled.

Disable the “View Result Tree” listener as it consumes a lot of memory and can result in the console

freezing or JMeter running out of memory. It is, however, safe to use the “View Result Tree”

listener with only “Errors” checked.

Rather than using lots of similar samplers, use the same sampler in a loop, and use variables (CSV

Data Set) to vary the sample. Or perhaps use the Access Log Sampler.

Don't use functional mode.

Use CSV output rather than XML.

Only save the data that you need.

Use as few Assertions as possible.

Disable all JMeter g raphs as they consume a lot of memory. You can view all of the real time g raphs

using the JTLs tab in your web interface.

Do not forg et to erase the local path from CSV Data Set Config if used.

Clean the Files tab prior to every test run.