apachejmeter-111018071425-phpapp01

7/29/2019 apachejmeter-111018071425-phpapp01

1/37

APACHEJMETER


2/37

WHATIS JMETER

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.


3/37

THEBENEFITSOF JMETER

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


4/37

DRAWBACKSOF JMETER

Its open source! Theres no guarantee ofsupport or further development.However, dont consider this a real

problem with a tool like JMeter, whicheasily can be replaced by another tool.

Getting "correct" response times fromJMeter forces you to understand how tomake a realistic client/server setup. Ifyoure not careful you might end up

measuring some incidental bottleneck,like your own workstations capacity. Onthe other hand, but youd have toconsider things like this with any tool!


5/37

WHATITMEANSFORYOU

Testing performance both on static and dynamicresources

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 analyzeoverall performance under different load types.

Graphical Analysis / Exporting Test Results


6/37

INSTALLATIONLatest 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 JMeterclicking on the JMeter.bat in Windows and JMeter file in UNIX.
http://jakarta.apache.org/site/binindex.cgihttp://jakarta.apache.org/site/binindex.cgihttp://jakarta.apache.org/site/binindex.cgi


7/37

IMPORTANTTHINGSTOBE

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.


8/37

CATEGORY IDENTIFICATION

Consider a simple three tier architecture

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

Application/Web

Server

C

L

IE

N

T

Database

Server


9/37

SIMILARLY

So JDBC requests are issued by multipleusers to access the database and HTTP

requests are issued when a website isaccessed and the client sends request tothe server.

We can of course extend the different typesof request depending on the applicationarchitecture. Some of the common typesof requests are FTP, HTTP, JDBC, JavaObject, LDAP.


10/37

SAMPLEAPPLICATION

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.


11/37

JDBC TEST PLAN

The JDBC Test Plan includes the following sections:

1. Creation of Thread Group

2. Adding the JDBC Requests

3. Adding Listeners to view or store results.

4. Saving the test plan.

5. Running the test plan.

We will demonstrate how to use ApacheJMeter to test the performance of the databaseserver when multiple users are trying to accessit.


12/37

CREATINGTHE THREAD

GROUPWhen you start JMeter, then you get the following screen. By

default the tree structure contains two elements-Test Plan

and WorkBench.


13/37

CREATIONOF THREAD

GROUPA 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.


14/37

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 beexecuted.


15/37

You can set the following properties:

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

Number of Threads -- the number of threads created. Each threadrepresents a single user. Therefore, if you want to simulate a load testwith 10 concurrent users, enter 10 as the value for this property.

Ramp-Up Period-- the number of seconds JMeter will take to accelerateto create all of the threads needed. If the number of threads used is 10and the ramp-up period is 20 seconds, JMeter will take 20 seconds tocreate those 10 threads, creating one new thread every two seconds. Ifyou 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 testfor the number of times entered in the Loop Count box.

Loop Count--this property value only has an effect if the Forever checkbox is unchecked. It tells JMeter the number of times it has to repeat thetest.


16/37

CREATINGA JDBC

REQUESTNow select the thread group name and right click on it to go to Add>Sampler>JDBC

Request. This brings you to the following screen.


17/37

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

select * from cityweather where cityname like Bangalore;

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


18/37

ADDING LISTENERSThis helps you to view the results and to store the results in a file. To

add listeners select the thread group and Add>Listener


19/37

SAVINGN RUNNINGTHE TEST

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.


20/37

LISTENINGTOTHE RESULT


21/37

CREATINGA HTTP

REQUESTThis is done by right clicking on the Thread Groupnode. Then

selectAdd / Sampler / HTTP Request:


22/37

In the next page the following screen comes up:


23/37

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 athread group.

Server Name or IP -- the server name or the IP address of the machinerunning the application being tested.

Port Number-- the port number used by the application. Normally, a Webapplication 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 andDelete 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.


24/37

Select the format of the results

This is done by again right clicking on the Thread Groupnode. Then selectAdd / Listener / View Results Tree:

This will give us a page containing the results of everyrequest:

Run the test plan

You do this by selecting Run from the menu, and thenStart(or Ctrl-R):

View the results

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


25/37

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.


26/37

ADDMORELISTENERS

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 Tablelistener. Heres what it

would display after 10 new iterations:


27/37

If we only want a summary of the run we can add anAggregate Report

listener:

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


28/37

ENHANCINGTHE TEST

PLANYou have now seen the basic elements used in a test plan. Weadded 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.

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

1. Inserting a timer

2. Recording a used case

3. HTTP Request Defaults


29/37

INSERTINGA TIMERBy default, a JMeter thread sends requests without pausing

between each request. We recommend that you specify adelay by adding one of the available timers to your ThreadGroup. If you do not add a delay, JMeter could overwhelmyour 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 thatamount of time.

Well now add a Timer element to get a more realistic testscenario. We select a Uniform Random Timer, where the

timer delay for each request is defined as a fixed part plus a


30/37

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.


31/37

RECORDINGA USE CASE

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 auser 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.


32/37

INCASEIFRECORDINGDOES

NOTWORK..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 Serverelement to

the WorkBench node:


33/37

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

P R


34/37

HTTP REQUEST

DEFAULTS

By using Http Default Request which can be added by

right click on the thread group and select Http

Request Default fromAdd/Config elements/Http

Request Defaultsand 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


35/37

INTERPRETINGTHE

RESULTS

The Best listener to interpret the result is

Aggregate Report. The figure shows the test

result in Aggregate Report


36/37

RESULTS

Min: 88 - The minimum time perrequest (in milliseconds)

Max: 2217 - The maximum time arequest took (worst case scenario)

Average: 388 - This is pretty much theperformance to be expected underheavy load

Error: 0.2% - The server failed underthat stress and refused 0.2% of theconnections. This is a Tomcat failure.


37/37

QUESTIONS ??

Documents

apachejmeter-111018071425-phpapp01