Load With JMeter PDF

Testing Web Application Using Jmeter
Index
1. Jmeter Features and Overview
2. Comparing Jmeter with other Performance Testing Tools
3. Introduction about IMSSPL site
4. Test Environment
5. Types of Testing
6. Functional Testing Approach
7. Load Testing Approach
8. Stress Testing Approach
9. Stability Testing Approach
10.Testing on virtual client/server environment
11. Comparing the results of Normal and Virtual environment
Apache JMeter Features & Overview

Apache JMeter is a powerful desktop performance tool from the Apache Jakarta project,
written in Java, for load-testing web pages, web applications, and other static and
dynamic resources including databases, files, Servlets, Perl scripts, Java Objects, FTP
Servers, and more. The main component in JMeter is the Java Swing-based Graphical
User Interface which can be used for both Scripting and Execution.
Excellent cost saving solution for small projects as it is an open source tool.
Robust in handling complex test scenarios that demand n number of virtual
users.
Complete portability and supports 100% all the Java based applications.
Less scripting efforts as compared to other tools because of its user effective GUI.
Is used to conduct Functionality, Load, Stress, Volume & Endurance tests on the
Web & Web-service based applications.
HTTP load testing can be done without any adding additional plugging samplers.
Since it is Java based, the tool was highly compatible with most of the Java based
requests i.e. it can be used to directly test the Java requests, JDBC requests and
JMS publisher & Subscriber. Hence it is a very good cost effective solution for
small development activities as well.
Comparing Jmeter with other Performance Testing Tools :

Sr. No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Item
Unlimited Load generation
Supports IP spoofing
Large download performance
Server monitoring
Batch Mode
Ease - Installation
Ease Script Authoring
Ease Running Tests
Results Reporting
Agent Management
Cross Platform
Cost
Technical Level
Stability/Bugginess
Transaction power
Custom protocols
Scalability of Agent
Slow sockets
External libs usable
Load Scheduling
Scalability of Controller
Real-time test monitoring
Real-time load adjustment
Script management
Script Development Environment
Load Runner
NO
Yes
Yes
Yes
NO
NO
Yes
neutral
Yes
Yes
NO
NO
Yes
neutral
Yes
Yes
Yes
Yes
Yes
Yes
neutral
Yes
Yes
Yes
Yes
JMeter
Yes
NO
NO
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
NO
neutral
Yes
neutral
neutral
Yes
Yes
NO
Yes
NO
Yes
NO
The Grinder
Yes
Yes
neutral
Yes
Yes
Yes
Yes
neutral
NO
NO
Yes
+
NO
neutral
Yes
Yes
neutral
NO
Yes
NO
+
neutral
NO
NO
NO
We find Jmeter is appropriate for testing our web-site because its free, its ease
of Installing/Recording and Reporting. We can increase loads till application's tolerance
point. We can use it on linux/windows environment etc...
Installation Requirements:
JMeter requires a fully compliant JVM 1.5 or higher because JMeter uses only
standard Java APIs, please do not file bug reports if JRE fails to run JMeter
because of JRE implementation issues.
Operating System : JMeter is a 100% Java application and should run correctly
on any system that has a compliant Java implementation. JMeter has been tested
and works under:
Unix (Solaris, Linux, etc)
Windows (98, NT, XP, etc)
OpenVMS Alpha 7.3+
Installation:
The most recent release of Jmeter, we can download from JMeter's site.
Downloads area available as either .gz or .zip file. To install a release build, simply
unzip the zip/tar file into the directory where we want JMeter to be installed. Provided
that we have a JRE/JDK correctly installed and the JAVA_HOME environment variable
set.
Running Jmeter:
To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are
found in the bin directory. After a short pause, the JMeter GUI should appear. The user
interface has two panes.
The left pane displays the elements used in testing. Initially, there are two subelements, Test Plan and WorkBench. Add an element to a node by right-clicking on
Test Plan and selecting Add. To remove an element, select the element by clicking
on it, then right-click on the element and choose the Remove option.
The right pane of the user interface displays the details of each element. We are now
ready to use Jmeter.
**Note
We should not run JMeter on the same machine running the application to be tested.
JMeter may use extensive resources that might affect the other application's performance
if they are both run on the same machine.
Apache JMeter Limitations:
Reporting Framework Limitations

Does not provide enough statistics: Most of the open source tools (JMeter as well)
does not provide the client side statistics summary reports in a presentable format
as available with the other popular commercial tools such as HP Load Runner
and Borland Silk Performer.
Huge Log Files: Added to that JMeter provides the log details for every user and
every iteration thus in turn causing the log files generated to be very huge.
Manual Effort: Analyzing such voluminous log files involves a lot of manual
effort in order to create highly sophisticated analysis reports.
Time Consuming: Above all, creating the final customer presentable summary
report consumes huge amount of time.
AJAX components cannot be interpreted by Jmeter.
Cannot collate the Running V-users data correctly in a Distributed Load Testing
conducted using multiple Load Generators.
Cannot monitor the Server related components.
There is no feature which allows to pass all the requests concurrently at the same
time unlike in other commercial tools.
Introduction about IMSSPL Web site

This is a website of Integra Micro Software Services Pvt Ltd. Integra Micro Systems is a
group of companies with more than twenty-eight years of experience in the development
of computer software technology and applications.
The website consists of below Key elements to get a clear vision about the
Company and its features.
About Us
Competency
Contact
Service Offerings
Why Integra-Services
Careers
Resources Center
General Group people using this website:

About Us : Mostly Viewed by Business group of People, Clients, Consulting
Companies,New Joiners, etc.
Contact Us : Mostly Viewed by Employees of other Company,Clients,etc
Careers : Mostly Viewed by Students,Freshers,etc
This Website can be tested using Jmeter with the following

Testing Methodologies.
Functional
Testing
Load Testing
Stress Testing
Stability Testing
Basic necessity to check this website is whether the server of the site is rendering its
services properly to the general group of users or not. To fulfill this criteria, above
mentioned testing is required.
To undergo Functional Testing using Jmeter

Identify any key element (like About Us)--> Select any Quotation or phrases or word)
and with the help of Assertion, execute Functional Testing. In Functional Testing the
Thread Group or number of users can be one or more than one .
To undergo Performance Testing:

Stress Testing:
Stress Testing is done by identifying out the Break point by incresing the
Number of Users accessing the same Key element in that particular website
for how much duration and at what intensity.
Stress testing will determine the performance of the particular site and check
the strength of Non-Functionality of the particular Website.
Under Stress Testing the Number of Thread Groups or Users need to be
increased gradually and check where the Break point is and when the system
would start behaving unexceptionally and cannot withstand the load with the
particular resources available.
Stability testing:
Stability Testing is done to check, up to what an extend the system is stable

and cannot extend its load as compared to the intensity of the load.
Stability Testing is similar as Stress testing ,only we are not concerned of
finding the Break point,its only related to how much a system can maintain.
Under stability testing the number of thread Groups or Users accessing the
system or particular Key element in that Website is just the Threads Group
numbers before the system started behaving unexceptionally in stress
testing.
Load Testing:
Load Testing is done to check how the system behaves under certain load
condition.
How the system is expected to behave under certain circumstances like : Provide
the system with certain Input and the Desired Output is achieved or not ,as
compared to the load condition.
Under Load Testing the number of Thread Groups or Users accessing the system
or particular Key element in that Website may be 500 or 600,compared as per the
intensity of the users using that website and as per the publicity of the Website.
Functional Testing
JMeter is found to be very useful and convenient in support of functional
testing. Although functional testing elements can be integrated within the Test Plan,
which was originally designed to support load testing. Many other load-testing tools
provide little or none of this feature, restricting themselves to performance-testing
purposes. Besides integrating functional-testing elements along with load-testing
elements in the Test Plan, we can also create a Test Plan that runs these exclusively. In
other words, aside from creating a Load Test Plan, JMeter also allows us to create a
Functional Test Plan. This flexibility is certainly resource-efficient for the testing
project.
JMeter does not have a built-in browser, unlike many functional-test tools. It
tests on the protocol layer, not the client layer (i.e. JavaScripts, applets, and many more.)
and it does not render the page for viewing. Although, by default that embedded
resources can be downloaded, rendering these in the Listener | View Results Tree may
not yield a 100% browser-like rendering. In fact, it may not be able to render large
HTML files at all. This makes it difficult to test the GUI of an application under testing.
However, to compensate for these shortcomings, JMeter allows the tester to
create assertions based on the tags and text of the page as the HTML file is received by
the client. With some knowledge of HTML tags, we can test and verify any elements as
we would expect them in the browser.
It is unnecessary to select a specific workload time to perform a functional
test. In fact, the application we want to test may even reside locally, with our own
machine acting as the "localhost" server for our web application. For this article, we will
limit ourselves to selected functional aspects of the page that we seek to verify or assert.
Performance Testing
Performance testing of an application / system is basically the process of
understanding how the application and its operating environment behave at various user
loads. In general, it is performed by simulating virtual users to determine / validate the
scalability, availability, robustness, hardware & software resource utilization of the
application thus ideally paving the way for effective capacity planning of the system for
future usage.
One of the main objectives of performance testing is to help maintain the system with
low latency, high throughput, and low utilization.
Various types of Performance Testing include:

Load Testing
Stress Testing
Stability Testing
Need for Performance Testing

Performance Testing sets the best possible performance expectation under a given
configuration of infrastructure. It also highlights early in the testing process if changes
need to be made before application goes into production. Some of the reasons for which
Performance Testing has to be mandatory carried out are:
Poor Response Time: A critical web page may take one minute to show up. The
expected response time is less than 10 seconds.
Scalability: When 100 users from new branch were introduced into the system,
the application was unable to handle the additional load and response times
degraded from 5 seconds to 50 seconds.
Batch Window Issues: The batch upload that is supposed to happen in a 1AM to
7AM window does not complete till 9:30 AM. This impacts the availability of
data for online applications.
Availability: The application server needs to be restarted owing to resource leaks
within the application. This causes a downtime of at least 0.5 hours a day.
Resource Capacity Planning: An application consumes 90% CPU on a server
that is supposed to host another application after 3 months . There is no extra
capacity to take this additional load.
Costs associated with Performance testing

Performance testing usually has huge costs associated with it. The costs associated
with Performance testing can be categorized as
The Investment made on the Performance testing tool.
Time consumed in Preparation of test data.
The Load Testing Infrastructure / environment setup should be as close as
possible to the production environments.
In case of administrative organizations, acquiring the required permissions is a
tedious process, since performance tests typically require many administrative
rights.
Core Performance Testing Activities:

The following are some of the key activities during the successful implementation of
Performance testing using Jmeter:
Define Performance Test Goals and create a Performance Test Plan.
Create JMeter Scripts for identified critical business flows and execute various
load test scenarios.
Prepare customized analysis summary reports for every test execution and an
overall Engagement Summary Report at the end of the engagement.
Based on the performance bottlenecks identified, provide suggestions to the
application development team for tuning the application. Test executions are
thus run in iterative manner until the desired acceptance criteria are met.
-----------------------------------------------------------------------------------------------------------
Functional Testing Approach:

Identify Features: Identify all the features to be tested using Jmeter
Plan and Design Test: Identify the pattern to be verified in the response from
server and design test cases accordingly
Configure Test Environment: Setting up the whole test environment
identified
Implement Test Design: Using Jmeter, implement all the Test cases
Ex1ecute Test Cases: Merge and Execute all functional test cases (Ctrl+R)
Analyze Report and Retest: By execution find out the results and report all
the defects if any. After resolving those defects retest new build with the same scripts
Identified Features:
We will create a Test Plan(imsspl Website) in order to demonstrate how we
can configure the Test Plan to include functional testing capabilities. The modified Test
Plan will include these scenarios:
1. Navigate to Home page
2. Navigate to About Us page and its options
3. Navigate to Competency page and its options
4. Navigate to Service Offerings page and its options
5. Navigate to Why Integra-Services page and its options
6. Navigate to Careers page and its options
7. Navigate to Resource Centre page and its options
8. Navigate to Contact page and its options
Following these scenarios, we will simulate various entries and form

submission as a request to a page is made, while checking the correct page response to
these user entries. We will add assertions to the samples following these scenarios to
verify the 'correctness' of a requested page. In this manner, we can see if the pages
responded correctly to invalid data.
Plan and Design Test:

Imsspl Website Functional Sample Test Cases:
Test Steps
Data
Expected
Verify user is able to 1.Open Jmeter

navigate on About 2.Add Thread group under test plan with single thread
Us page when click 3.Add Http Request under thread group
* Server IP :- 10.30.10.184
on About Us option
It should display as
pass in Assertion Result
in Jmeter.

navigate on
2.Add Thread group under test plan with single thread
Competency page 3.Add Http Request under thread group
when click on
* Server IP :- 10.30.10.184
Competency option
* Path :- /imsspl/index2.php?content=competency
4.Add Response Assertion under Http Request
* Apply To : - Main Sample Only
* Response field to Check :- Text Response
* Pattern Matching Rules :- Contains
* Pattern To Test : - Click on Add button and Give Keyword
Competency
5.Add Assertion Result Listeners in thread group
6.Click on run option
7.Select Start Option
in Jmeter.
Verify user is able to

navigate on Service
Offerings page
when click on
Competency option
in Jmeter.
* Path :- /imsspl/index2.php?content=about_us
* Pattern To Test : - Click on Add button and Give Keyword About
Integra-Services
1.Open Jmeter
3.Add Http Request under thread group
* Server IP :- 10.30.10.184
* Path :- /imsspl/index2.php?content=services
Service Offerings


navigate on
Careers page
when click on
* Server IP :- 10.30.10.184
Careers option
* Path :- /imsspl/index2.php?content=careers
Careers/We not only build careers but a long lasting
relationship.
Or Add all word/string together
in Jmeter.

navigate on
Resource Centre 3.Add Http Request under thread group
page when click on
* Server IP :- 10.30.10.184
Careers option
* Path :- /imsspl/index2.php?content=resources
Resource Centre.
Or Add all word/string together
in Jmeter.

navigate on
Contacts page
when click on
* Server IP :- 10.30.10.184
Contact option
* Path :- /imsspl
Contact
in Jmeter.
Configure Test Environment:

The following Environment has been set up
Client Side:
PC with Petntium-4
Atleast 20 GB free HDD
512 MB SD-RAM
Jmeter 2.4
Linux 5.5 /Windows XP/Vista
URL : http://10.30.10.184/imsspl
Mozilla Browser 3.0.5
Server Side:
PC with Petntium-4
Atleast 100 GB free HDD
1 GB SD-RAM
TomCat server 6.0
Implement Test Design:

Using HTTP Proxy Server to Record Page Requests:
We will need to include the HTTP Proxy Server element in the WorkBench.
Some configuration will be required, as shown in the following snapshot:
Configuring the Proxy Server:

Simulating these scenarios will require JMeter to make requests for accessing
the home pages, About us page, Competency page, etc.

Selecting Add Assertion will be especially useful as we add specific patterns
of the page that we want to evaluate as a later part of this exercise. The Capture HTTP
Headers option is selected to capture the Header information as we begin recording.
However, to make the recording neater, we will keep this option unchecked.
In addition, since we do not require images in our testing, in the URL Pattern
to Exclude section, add these patterns: .*.jpg, .*.js, .*.png, .*.gif', .*.ico, .*.css,
otherwise these image files, which are not necessary for our testing, will be recorded
causing unnecessary clutter in our recording.
Adding HTTP Request Default:

A useful addition to this element is the HTTP Request Default element, a type
of Configuration element. Since this Test Plan will employ multiple HTTP request
elements targeting the same server and port, this element will be very useful. The web
server name will not be captured for each HTTP Request sampler record, since the
Request Default element will retain this information. With a little configuration change
in this element, it allows the Test Plan to run even when the application is the deployed
to a different server and/or port. The following snapshot is the HTTP Request Default
element that we will use for this exercise.
As we use this default element, our subsequent recording never needs to append the
Server name. The result of our recording of the first page is shown in the following
snapshot:
Adding HTTP Header Manager:

Another very useful default element is the HTTP Header Manager
Configuration element. This element can either be added to the Test Plan and configured
manually as an afterthought. Once the Proxy Server records the homepage request, stop
the recording. We will find a Header Manager for this page is being captured. Simply
click and drag this element to the top of the current scope of the HTTP Proxy Server.
Notice that I have removed the Referrer, since we want to create a default for the
remaining HTTP Requests. Following is a snapshot of this change.
Now,we may de-select the Capture HTTP Headers option in the Proxy Server
element, since we have the default header.
Or there is another process also to do these steps :1.Add thread groups as child of Test Plan as displaying in fig below.
2.Now change the name of each thread group as according to requirements as like
showing in figure given below.
Let the Recording Begin...

Let us proceed with the recording following the test cases in the previous table as our
guide. As you record each page, select the specific tags or page elements the correctness
of which you want to validate and add them to the Patterns to Test section in the
Response Assertion element of each sampler. This may take most of your recording
time, since as you record, you need to decide carefully which page element(s) would be
the most effective measure of correctness. There are plenty of developer tools available
to help you in this possibly tedious task.
The Assertion Results listener is used with the Response Assertion elements, to
summarize the success or failure of a page in meeting the validation criteria defined in
each Response Assertion.
Execute Test Cases:

Once the assertions are properly completed, we are expecting that running our
Test Plan would pass all the assertions. Passed assertions will not show any error in
Assertion Results | Listener installed within the same scope. As for all Listeners,
results as captured by the Listeners can be saved and reproduced at a later time.
Following is a sample explaining what passed Assertions would reveal as the Test is
executed.
On the other hand, a failed Assertion would show an error message in the same Listener
as the following snapshot illustrates.
Since a page error or Page not found error is a real risk in web applications, a failure
may originate from such an error, and not just because of a failed Assertion. We can
view more information about the sampler that contains the failed Assertion to investigate
the origins of a failure. A View Results Tree Listener records the details of requests and
logs all errors (indicated by the red warning sign and red fonts).
Summary
This will provide visual means for us to understand the capabilities of JMeter tools that
support functional testing, as we directly wrote and implemented a JMeter script. We
have demonstrated building a Test Plan to contain functional validations (or assertions)
by incorporating various essential JMeter components, particularly the 'Response
Assertion' element and 'Assertion Result' Listener. By using the 'User Defined Variable'
Configuration element, we have also parametrized several values in order to give our
Test Plan better flexibility. In addition, we have observed the result of these assertions as
we performed a 'live' run of the application under test. An HTTP Request sampler may
require to be modified, if there are any changes to the parameter(s) that the sampler
sends with each request.
Load Testing Approach
Identify Requirements
Identify load-critical scenarios
Identify the target load levels
Implement test Design
Design specific tests
Run tests
Analyze the results
Load Testing:
Load Testing is done to check how the system behaves under certain load
condition.
How the system is expected to behave under certain circumstances like :
Provide the system with certain Input and the Desired Output is achieved or
not ,as compared to the load condition.
Under Load Testing the number of Thread Groups or Users accessing the
system or particular Key element in that Website may be 500 or 600,compared
as per the intensity of the users using that website and as per the publicity of
the Website.
Identify Load Requirements

Load testing helps to identify the maximum operating capacity of an
application as well as any bottlenecks that might interfere with its operating at capacity.
As you begin load testing, it is recommended that you start with a small number of
virtual users ( by giving 1 user in the Thread Group) and then incrementally
increase the load from normal to peak (by giving the number of users as 500 in the
Thread Group) .
We can then observe how our application performs during this gradually
increasing load condition. Eventually, we will cross a threshold limit for our
performance and load objectives.
For example, we might continue to increase the load until the server processor
utilization reaches 75 percent, or when end-user response times exceed 5 seconds.
Identify the load-critical scenarios.

1. Identify the workload profile for distributing the entire load among the key
scenarios.
2. Identify the metrics that you want to collect in order to verify them against your
performance objectives.
By using an iterative testing process, these steps should help you achieve your
performance objectives.
We will create a Test Plan(imsspl Website) in order to demonstrate how we can
configure the Test Plan to include load testing capabilities. The modified Test Plan will
include these scenarios:
Access to Home page
Access to About Us page and its options
Access to Competency page and its options
Access to Service Offerings page and its options
Access to Why Integra-Services page and its options
Access to Careers page and its options
Access to Resource Center page and its options
Access to Contact page and its options
Designing Load Test:

Imsspl Website Sample Load Test Cases:
Test Description
1
Test Steps
Verify that 500 users 1.Open Jmeter

are accessing About 2.Add Thread group under test plan with single thread
us page and its
options.
* Server IP :- 10.10.10.47
* Path :- /imsspl must
be in accessible mode.
Expected
500 users should be
able to access the
home page with in sec
average time
1. Start Apache Jmeter 2.4 and run home-page.jmx file in Jmeter

2. After successful execution refer Home-Page_Aggregate for
performance analysis for this load type.

us page and its
options.
* Server IP :- 10.10.10.47
500 users should be

able to access the
average time

2. After successful execution refer Home-Page_Aggregate.csv for

us page and its
options.
* Server IP :- 10.10.10.47
500 users should be

able to access the
average time


us page and its
options.
* Server IP :- 10.10.10.47
500 users should be

able to access the
average time


us page and its
options.
* Server IP :- 10.10.10.47
500 users should be

able to access the
average time


us page and its
options.
* Server IP :- 10.10.10.47
500 users should be

able to access the
average time
Implementing Load Test Cases in jmeter:

JMeter does not have a built-in browser, unlike many Load-test tools. It tests
on the protocol layer, not the client layer (i.e. Java Scripts, applets, and many more.) and
it does not render the page for viewing. Although, by default that embedded resources
can be downloaded, rendering these in the Listener | View Results Tree may not yield a
100% browser-like rendering. In fact, it may not be able to render large HTML files at
all. This makes it difficult to test the GUI of an application under testing.
However, to compensate for these shortcomings, JMeter allows the tester to
add Summary Report | Spline Visualizer |Aggregate Graph | Aggregate Report |
View Result Table , which will display the content of load testing in the form of
graph,to visualize the test cases and test scenarios ,in a better and easily accessible way.
With some knowledge about these Listeners, we can test and verify any number of
elements as we would expect them in the browser.
It is necessary to select a specific workload time to perform a load test. In fact,

the application we want to test may even reside locally, with our own machine acting as
the "localhost" server for our web application. For this article, we will limit ourselves to
selected load aspects of the page that we seek to verify or determine using summary
report.
We can access to any of the pages and by increasing the load or number of
Thread Groups, Test Plan of Load Testing using Jmeter is prepared. Following these
scenarios, we will simulate various entries and form submission as a request to a page is
made, while checking the reult of the page to the number of user entries. We will add
Summary Report to the samples following these scenarios to verify the 'load capacity' of
a requested page. In this manner, we can see if the pages respond properly or not to the
allotted load , and if the page is not responding properly means the page cannot handle
the given load capacity.
Using HTTP Proxy Server to Record Page Requests
We will need to include the HTTP Proxy Server element in the WorkBench. Some
configuration will be required, as shown in the following snapshot:
Configuring the Proxy Server

Simulating these scenarios will require JMeter to make requests for accessing the home
pages, About us page, Competency page, etc.
Selecting Add Assertion will be especially useful as we add specific patterns of the page
that we want to evaluate as a later part of this exercise. The Capture HTTP Headers
option is selected to capture the Header information as we begin recording. However, to
make the recording neater, we will keep this option unchecked.
Same as Functional Testing pattern:

In addition, since we do not require images in our testing, in the URL Pattern to Exclude
section, add these patterns: .*.jpg, .*.js, .*.png, .*.gif', .*.ico, .*.css, otherwise these
image files, which are not necessary for our testing, will be recorded causing
unnecessary clutter in our recording.But for Load testing we can add these images as it
will only increase to the load case scenario.
Adding HTTP Header Manager
Another very useful default element is the HTTP Header Manager Configuration
element. This element can either be added to the Test Plan and configured manually as
an afterthought. Once the Proxy Server records the homepage request, stop the
recording. We will find a Header Manager for this page is being captured. Simply click
and drag this element to the top of the current scope of the HTTP Proxy Server. Notice
that I have removed the Referrer, since we want to create a default for the remaining
HTTP Requests. Following is a snapshot of this change.
Now,we may de-select the Capture HTTP Headers option in the Proxy Server
element, since we have the default header.
Or there is another process to do this thing like:3.Add thread groups as child of Test Plan as displaying in fig below.
4.Now change the name of each thread group as according to requirements as like
showing in figure given below.
Let the Recording Begin...

3. Let us proceed with the recording following the test cases in the previous table as
our guide. As you record each page add the number of users as per the requirement for
load Testing ( let it be 500 users) in the Thread Group. Now we can analyze the result.
The Aggregate Graph , View Result Tree , View Results in Table listeners are used
with the Test Plan elements, to summarize the success or failure of a page in meeting the
validation criteria defined in each Load Thread Group.
Running the Test:

Once all the Listeners are added the Test Plan is Run and results as captured
by the Listeners which can be saved and reproduced at a later time. Following is a
sample explaining the different listeners with a Test Plan to execute the test. A View
Results Tree Listener records the details of requests and logs all errors (indicated by the
red warning sign and red fonts).
Analysis on Load Testing Results :5. Analyze the metric data captured during the tests.
Aggregate Graph:
The aggregate graph is similar to the aggregate report. The primary difference
is the aggregate graph provides an easy way to generate bar graphs and save the graph as
a PNG file. By default, the aggregate graph will generate a bar chart 450 x 250 pixels.
Summary Report :
The summary report creates a table row for each differently named request in your test.
This is similar to the Aggregate Report , except that it uses less memory.
The throughput is calculated from the point of view of the sampler target (e.g. the
remote server in the case of HTTP samples). JMeter takes into account the total time
over which the requests have been generated. If other samplers and timers are in the
same thread, these will increase the total time, and therefore reduce the throughput
value. So two identical samplers with different names will have half the throughput of
two samplers with the same name. It is important to choose the sampler labels correctly
to get the best results from the Report.
View Result Table :
This Visualizer creates a row for every sample result. Like the View result Tree this
Listener uses a lot of memory space
Summary :
This will provide visual means for us to understand the capabilities of JMeter tools that
support Load testing, as we directly wrote and implemented a JMeter script. We have
demonstrated building a Test Plan to contain Load testing by incorporating various
essential JMeter components, particularly the 'Aggregate Graph' element and 'Summary
Report' Listener.
Stress Testing Approach:

Step1 - Identify test objectives:
Step 2 - Identify key scenarios:
Step 3 - Identify the workload:
Step 4 - Identify metrics:
Step 5 -Implement test cases:
Step 6 - Simulate load and Run:
Step 7 - Analyze results:
Objective of Stress Testing:

To observe the results when testing our web-site beyond normal operational
capacity, till its breaking point by slowly increasing the load.
Key scenarios:
In first test case, there are ten threads, particular number of users will access
home page, and top menu options like About Us, Competency, Service
Offerings, Why Integra-Services, Careers, Resource Centre, Contact Us,
Home, Privacy Policy. In second and third test cases, we are navigating to the submenus and recording it.
Defining Workload:
Starting from 100 users, we are increasing user count by 200, 400, 800.. till No
response from server. All these virtual users are simultaneously accessing with the
functions given under key-scenarios.
Metrics to be collected:
Average Response Time and Throughput values will be collected after execution
Sample Test cases:

Test Case
ID
Test
Description
Test Data/ Function Prototype
Observation
Stress_01
Find how
many
concurrent
users can
perform given
functionalities.
1.Open Jmeter
2.Add 10 Thread groups under test plan
3. Do proxy setting and record the following functions for
each thread groups
For 100 users

Average Time taken : 1.67
Seconds
Throughput : 34/Sec
a. Open http://10.30.10.184/imsspl/
b. Click on About Us.
c. Click on Competency.
d. Click on Service Offerings.
e. Click on Why Integra-Services.
f. Click on Careers.
g. Click on Resource Centre.
h. Click on Contact Us.
i. Click on Home.
j. Click on Privacy Policy .
For 200 users

Seconds
Throughput : 31.6/Sec
For 400 users
Seconds
For 800 users

4. Set No. Of Threads = 10 for each thread group.
Ramp-up period = 0
Seconds
(No of simultaneous users now = 100) and RUN Jmeter
Throughput : 28/Sec
th
5. Repeat the 4 Step by increasing No. Of threads by 10
No Response for 840 Users.
each time till No response from server. ( 10, 20, 30 ...)
Conclusion : Approximately 800
users can access the server by
the given functions
Stress_02
Find how
many
concurrent
users can
perform given
functionalities.
1.Open Jmeter
each thread groups
For 100 users

Seconds
a. Open http://10.30.10.184/imsspl/
b. Click on About Us select vision
c. Click on Competency select Mobility Solutions
d. Click on Service Offerings select Contract R&D
e. Click on Why Integra-Services select Value
Proposition
f. Click on Careers select Current Opportunities
g. Click on Resource Centre select Corporate
Profile
h. Click on Contact Us select Corporate
Headquarters
i. Click on Home button at top right corner.
j. Click on Privacy Policy at bottom of page.
For 200 users

Seconds
For 400 users
Seconds
For 800 users
Seconds
Throughput : 28/Sec

Ramp-up period = 0
Conclusion : Approximately 800
th
5. Repeat the 4 Step by increasing No. Of threads by 10 users can access the server by
the given functions
Stress_03
Find how
many
1.Open Jmeter
For 100 users

concurrent
users can
each thread groups
perform given
functionalities. a. Open http://10.30.10.184/imsspl/
b. Click on About Us select News and Events
c. Click on Competency select Networking
d. Click on Service Offerings select I18n and L10n
e. Click on Why Integra-Services select Quality
Policy
f. Click on Careers select Walk-Ins
g. Click on Resource Centre select Case Studies >
Information Development
h. Click on Contact Us select Infrastructure
i. Click on Sitemap button at top right corner.
j. Click on Terms of Use at bottom of page.
Seconds
Throughput : 35/Sec
For 200 users
Seconds
For 400 users
Seconds
For 800 users
Seconds

Ramp-up period = 0
5. Repeat the 4th Step by increasing No. Of threads by 10 Conclusion : Approximately 800
users can access the server by
the given functions
Implement test cases in JMeter:

In Jmeter record the steps given in Test cases in the same way as explained in
functionality Testing.
Simulating the load and Execute:

Set No. Of Threads = 10 for each thread group.
Ramp-up period = 0
Repeat the above steps by increasing No. Of threads by 10 each time till No
response from server. ( 10, 20, 30 ...)
Results Analysis :
For 100 users
Average Time taken : 1.67 Seconds
Throughput : 34/Sec
For 200 users
For 400 users
For 800 users
Throughput : 28/Sec
Conclusion :
Approximately 800 users can access the server by the given functions
Stability Testing Approach:

Step1 - Identify test objectives:
Step 2 - Identify key scenarios:
Step 3 - Identify the Duration:
Step 4 - Identify metrics:
Step 5 -Implement test cases:
Step 6 - Simulate load and Run:
Step 7 - Analyze results:
Objective of Stability Testing:

To confirm whether our web-site is continuously functioning well in or above
an acceptable period
Key scenarios:
Particular number of users will access home page, and top menu options like
About Us, Competency, Service Offerings, Why Integra-Services, Careers,
Resource Centre, Contact Us, Home, Privacy Policy and its sub-menu options
over a given duration.
Defining Workload:
To confirm whether our server is continuously responding well for 2 days
or for 10000 times for the repeated access with the same set of requests.
Metrics to be collected:
Average Response Time and Throughput values will be collected after execution
Sample Test cases:

Test Case
ID
01
Test
Description
Verify that 10
users are
simultaneously
able to access
Home Page
page , for
10000 times.
Test Data/ Function Prototype

1. Open http://10.30.10.184/imsspl/ site and Recor by
clicking on Home button in single thread group using
Jmeter
Observation
Server should be able to respond
all the requests successfully.
2. Select the thread and Set No Of Thread Group = 10

Ramp-Up period = 1
Loop Count is 10000
3. Run Jmeter
02
Verify that 10
users are able
to
simultaneously
access About
us page and
options
belongs to that
, for 10000
times.
1. Open http://10.30.10.184/imsspl/ site and record the

following functionalities in single thread group using
Jmeter
a. Home Page
b. About Us
c. Vision
d. Milestones Achieved
e. Our Strengths
f. Customers
g. Technology Partners
h. Business Partners
i. Executive Team
j. News and Events

2. No Of Thread Group = 10
Ramp-Up period = 1
Loop Count is 10000
3. Run Jmeter
03
Verify that 10
users are
simultaneously
accessing
Competency
page and
options
belongs to that
, for 10000
times.
1. Open http://10.30.10.184/imsspl/ site and record the

following functionalities in single thread group using
Jmeter
a. Telecom
b. Enterprise
c. Open Source
d. Technology
2. No Of Thread Group = 10
Ramp-Up period = 1
Loop Count is 10000
3. Run Jmeter

Implement test cases in JMeter:

In Jmeter record the steps given in Test cases in the same way as explained in
functionality Testing.
Simulating the load and Execute:

Enter: No Of Thread Group = 10
Ramp-Up period = 1
Loop Count is 10000
Now Run Jmeter (Ctrl+R)
Results Analysis :
If our Server is able to respond all the requests successfully over this duration
result is Pass.
Conclusion :
All Stability cases are Executed successfully 10000 times and All
cases are Passed.
Server Virtualization:
Definition: Server Virtualization is the masking of server
resources, including the number and identity of individual physical
servers, processors, and operating systems, from server users. The
server administrator uses a software application to divide one
physical server into multiple isolated virtual environments. The
virtual environments are sometimes called virtual private servers, but
they are also known as guests, instances, containers or emulations.
Virtual Server Environment:

PC with Petntium-4
10 GB free HDD
1 GB SD-RAM
TomCat server 6.0
Red hat Linux 9
Performance Testing Results Comparison:

All Load and Stability test cases are Pass in virtual Server also with the
same procedure as described in above sections.
The following results have been observed during stress testing.
Observation on Normal Server
Observation on Virtual Server
For 100 users

Throughput : 34/Sec
For 100 users

Throughput : 32/Sec
For 200 users

For 200 users

For 400 users

For 500 users

For 800 users

Throughput : 28/Sec
For 900 users

Throughput : 24/Sec

Conclusion : Approximately 800 users can access Conclusion : Approximately 900 users can access
the server by the given functions
the server by the given functions
It is observed that Virtual Server responds faster Because, its buffer memory(1GB
RAM Memory) is fully dedicated to our Website only. But some portion of RAM
memory of Normal server is reserved for some other applications. Otherwise we can
achieve almost same results in both environment.

Load With JMeter PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Load With JMeter PDF

Uploaded by

Copyright:

Available Formats

Testing Web Application Using Jmeter

Apache JMeter Features & Overview

Comparing Jmeter with other Performance Testing Tools :

Apache JMeter Limitations:

Reporting Framework Limitations

Introduction about IMSSPL Web site

General Group people using this website:

Contact Us : Mostly Viewed by Employees of other Company,Clients,etc

Careers : Mostly Viewed by Students,Freshers,etc

This Website can be tested using Jmeter with the following

To undergo Functional Testing using Jmeter

To undergo Performance Testing:

Stability Testing is done to check, up to what an extend the system is stable

Various types of Performance Testing include:

Need for Performance Testing

Costs associated with Performance testing

Core Performance Testing Activities:

Functional Testing Approach:

Following these scenarios, we will simulate various entries and form

Plan and Design Test:

Verify user is able to 1.Open Jmeter

Verify user is able to 1.Open Jmeter

Verify user is able to

6.Click on run option

Verify user is able to 1.Open Jmeter

Verify user is able to 1.Open Jmeter

Verify user is able to 1.Open Jmeter

Configure Test Environment:

Implement Test Design:

Configuring the Proxy Server:

the home pages, About us page, Competency page, etc.

Adding HTTP Request Default:

Adding HTTP Header Manager:

Let the Recording Begin...

Execute Test Cases:

Load Testing Approach

Identify Load Requirements

Identify the load-critical scenarios.

Designing Load Test:

Verify that 500 users 1.Open Jmeter

1. Start Apache Jmeter 2.4 and run home-page.jmx file in Jmeter

Verify that 500 users 1.Open Jmeter

500 users should be

1. Start Apache Jmeter 2.4 and run home-page.jmx file in Jmeter

Verify that 500 users 1.Open Jmeter

500 users should be

1. Start Apache Jmeter 2.4 and run home-page.jmx file in Jmeter

Verify that 500 users 1.Open Jmeter

500 users should be

2. After successful execution refer Home-Page_Aggregate for

Verify that 500 users 1.Open Jmeter

500 users should be

1. Start Apache Jmeter 2.4 and run home-page.jmx file in Jmeter

Verify that 500 users 1.Open Jmeter

500 users should be

Implementing Load Test Cases in jmeter:

It is necessary to select a specific workload time to perform a load test. In fact,

Configuring the Proxy Server

Same as Functional Testing pattern:

Let the Recording Begin...

Running the Test:

View Result Table :

Stress Testing Approach: