A PACHE JM ETER

W HAT

IS

J METER

Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed to test Web applications. However, it has been extended so that you can now test relational databases (via JDBCTM). Most important it is an open source tool.

T HE BENEFITS OF JM ETER ARE :

Its free! Its easy to use. It has a simple and intuitive GUI. This encourages you to use it from the start while youre developing your application Its open source. You may modify it or add new features--if you have the time and skills

D RAWBACKS

OF

JM ETER

Its open source! Theres no guarantee of support or further development. However, dont consider this a real problem with a tool like JMeter, which easily can be replaced by another tool. Getting "correct" response times from JMeter forces you to understand how to make a realistic client/server setup. If youre not careful you might end up measuring some incidental bottleneck, like your own workstations capacity. On the other hand, but youd have to consider things like this with any tool!

W HAT IT MEANS FOR YOU

Testing performance both on static and dynamic resources

Web Content
Web applications Web Services

Database Queries
FTP Servers TCP ..

It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. Graphical Analysis / Exporting Test Results

I NSTALLATION
Latest version of JMeter (jakarta-jmeter-2.0.2.zip or jakarta-jmeter-2.0.2.jar) can be downloaded from Apache site. Its a free tool available on net. Since its an open source; enough documentation and proper User Manual is hard to find.

Location for download

http://jakarta.apache.org/site/binindex.cgi#jmeter_binaries

Unzip the jakarta-jmeter-2.0.2.zip in your local machine. Start JMeter clicking on the JMeter.bat in Windows and JMeter file in UNIX.

I MPORTANT

THINGS TO BE CONSIDERED ..

-Identify the category under which the application falls,ie.FTP,HTTP,LDAP,JDBC -Creating the test plan.

-Inserting the timers.

-Running and saving the tests. -Analyzing the results and check for possible bottlenecks.

C ATEGORY I DENTIFICATION
Consider a simple three tier architecture

C L I E N T

Application/Web

Database Server

Server

The connection between the client and app server is a HTTP request and between the App server and the Database is JDBC. Then to test the performance of the database using a JDBC request and the HTTP connection using a HTTP request.

S IMILARLY
So JDBC requests are issued by multiple users to access the database and HTTP requests are issued when a website is accessed and the client sends request to the server. We can of course extend the different types of request depending on the application architecture. Some of the common types of requests are FTP, HTTP, JDBC, Java Object, LDAP.

S AMPLE A PPLICATION
Let us use the simple application architecture example previously described to illustrate the working of the tool.

Here as we would be testing both the server and the database performance, so we will create two test plans- JDBC Test Plan and HTTP Test Plan.

JDBC T EST P LAN

The JDBC Test Plan includes the following sections:
1. 2. 3. 4. 5.

Creation of Thread Group Adding the JDBC Requests

Adding Listeners to view or store results.

Saving the test plan. Running the test plan. We will demonstrate how to use Apache JMeter to test the performance of the database server when multiple users are trying to access it.

When you start JMeter, then you get the following screen. By default the tree structure contains two elements-Test Plan and WorkBench.

C REATING THE T HREAD G ROUP

C REATION OF T HREAD G ROUP

A thread group allows you to define the behavior of a group of threads that will interact with your application. Think of each thread as a person sitting at their computer, trying to access a given Web page. You will use thread groups to define the number of threads that a test will launch.Thread Groups are the place where we set the number of simulated users and number of iterations. The thread group has to be created under the Test Plan section.

Number of Threads: Number of users to be simulated.

Ramp Up Period: How fast the users are loaded.

Loop Count: How many times the test plan needs to be executed.

You can set the following properties:

Name -- the name of this thread group. You can give a descriptive name to this property.

Number of Threads -- the number of threads created. Each thread represents a single user. Therefore, if you want to simulate a load test with 10 concurrent users, enter 10 as the value for this property.
Ramp-Up Period -- the number of seconds JMeter will take to accelerate to create all of the threads needed. If the number of threads used is 10 and the ramp-up period is 20 seconds, JMeter will take 20 seconds to create those 10 threads, creating one new thread every two seconds. If you want all threads to be created at once, put 0 in this box. Forever -- if clicked, this option tells JMeter to keep sending requests to the tested application indefinitely. If disabled, JMeter will repeat the test for the number of times entered in the Loop Count box. Loop Count --this property value only has an effect if the Forever check box is unchecked. It tells JMeter the number of times it has to repeat the test.

Now select the thread group name and right click on it to go to Add>Sampler>JDBC Request. This brings you to the following screen.

C REATING A JDBC R EQUEST

Suppose we are testing a web based weather forecasting application, then in the last field we will need to enter the SQL query which will fetch the data from the database. Eg.

select * from cityweather where cityname like Bangalore;

Similarly we can create more JDBC requests which retrieves information of some more important cities.

A DDING L ISTENERS
This helps you to view the results and to store the results in a file. To add listeners select the thread group and Add>Listener

S AVING

R UNNING

THE

T EST

After configuring the listeners now we save the test and then select the option run from the menu bar to run the test.Once the test is run, the results are displayed as per the specification in the listener. The process of creating a HTTP Test Plan is similar except for creating the HTTP request instead of the JDBC request.

L ISTENING TO THE R ESULT

This is done by right clicking on the Thread Group node. Then select Add / Sampler / HTTP Request:

C REATING A HTTP R EQUEST

In the next page the following screen comes up:

On the HTTP Request screen, you configure the HTTP requests that will be used to "hit" your application. Here, you can set the following properties.

Name -- the name of this HTTP request. The name should be descriptive; remember that it is common to have multiple HTTP Request elements in a thread group. Server Name or IP -- the server name or the IP address of the machine running the application being tested. Port Number -- the port number used by the application. Normally, a Web application runs on port 80. Protocol -- the protocol used, either HTTP or HTTPS. Method -- the request method, either GET or POST. Path -- the path to the resource that will handle this request. Follow Redirects -- follows redirections sent by the Web application, if any. Parameters -- the list of parameters sent with this request. Use the Add and Delete buttons to add and remove parameters. Send a file with a request -- simulate a file upload to the Web application. Retrieve all images and Java Applets -- download embedded content.

Select the format of the results

This is done by again right clicking on the Thread Group node. Then select Add / Listener / View Results Tree: This will give us a page containing the results of every request:

Run the test plan You do this by selecting Run from the menu, and then Start (or Ctrl-R):

View the results When the run has completed the results can be the Results Tree: seen in

Here weve selected the first request in the upper pane. Below you can see the request that was generated, and the results, which is an HTML page with the text "Hello World!" (only the first part of the HTML is shown in the figure). We can also see the time it took to process the request: 110 milliseconds. Most of the other requests used less time than this.

A DD

MORE LISTENERS

One of the nice things about JMeter is its variety of listeners. If we want a tabular view of the requests we can add a View Results in Table listener. Heres what it would display after 10 new iterations:

If we only want a summary of the run we can add an Aggregate Report listener:

Heres how our test plan looks now with these two extra listeners added:

E NHANCING

THE

You have now seen the basic elements used in a test plan. We added a sampler and some listeners, but as could be seen in the menus on the last page there are many other elements that may be added to a test plan.

T EST P LAN

Lets add a couple of new elements to the test plan.

1. 2. 3.

Inserting a timer Recording a used case HTTP Request Defaults

I NSERTING

T IMER

By default, a JMeter thread sends requests without pausing between each request. We recommend that you specify a delay by adding one of the available timers to your Thread Group. If you do not add a delay, JMeter could overwhelm your server by making too many requests in a very short amount of time.

The timer will cause JMeter to delay a certain amount of time between each request that a thread makes.
If you choose to add more than one timer to a Thread Group, JMeter takes the sum of the timers and pauses for that amount of time. Well now add a Timer element to get a more realistic test scenario. We select a Uniform Random Timer, where the timer delay for each request is defined as a fixed part plus a

Set the minimum delay to 2 seconds, and the variable part to 1 second. This will simulate a user that sits and thinks between 2 and 3 seconds before giving the next request.

R ECORDING

U SE C ASE

One of the really useful features in JMeter is its ability to record what you do in your browser. If you want to make a test plan for a use case, where a user working with her browser goes through a series of screens, entering data, clicking on buttons and hyperlinks, then its quite a job to create the JMeter HTTP Request elements by hand. The HTTP Proxy Server is the solution to this task. The idea of a Proxy is to sit between your browser and the web server:

You must define this setup both in the browser and in JMeter. First you let the browser direct its requests to some port number, say 8090. In Internet Explorer v.5.5 you select Tools / Internet Options / Connections and then press either the LAN Settings or Settings button.

IN

CASE IF RECORDING DOES NOT WORK ..

Then its probably because your proxy settings arent quite correct.

In JMeter first remove all HTTP Request elements from your test plan. Keep only the report elements you want to use later on for viewing the results. The setup could look like this:

Then you let JMeter listen to the port number entered in your browser. You do this by adding the HTTP Proxy Server element to the WorkBench node:

Then you set the port number, and press the Start button at the bottom:

HTTP R EQUEST D EFAULTS

By using Http Default Request which can be added by right click on the thread group and select Http Request Default from Add/Config elements/Http Request Defaults and make the entry for application ip and port. In such a case if new Http Requests are added we need not again give the server ip and port for individual entry.

I NTERPRETING THE R ESULTS

The Best listener to interpret the result is Aggregate Report. The figure shows the test result in Aggregate Report

R ESULTS

Min: 88 - The minimum time per request (in milliseconds) Max: 2217 - The maximum time a request took (worst case scenario) Average: 388 - This is pretty much the performance to be expected under heavy load Error: 0.2% - The server failed under that stress and refused 0.2% of the connections. This is a Tomcat failure.

QUESTIONS ??