JMeter Training Lab - Intructor Guide
JMeter Training Lab - Intructor Guide
Instructor Guide
Table of Content
Step 3: Access the reference application home page (http://172.17.8.147:8080/) and log
using the following parameters:
- Login: [email protected]
- Password: test
Step 4: Perform some operations (add applicant, search applicants, update applicant,
remove applicant) in order to be familiar with the application.
2 JMETER INSTALLATION
2.1 Objective
Upon completion of this lab, you should be able to setup JMeter and to start it.
2.2 Exercises
Step 1: Download the latest version of JMeter from the following
http://jmeter.apache.org/download_jmeter.cgi
3.2 Exercise
3.2.1 Preparation
This exercise assumes that you have already acquired the minimum information on the
target application architecture and functionalities as well as the customer requirements.
The figure below presents the different interactions between the portlet “Job Application”
components:
The figure below presents the different interactions between the portlet “Job Applications
Manager” components:
- Clearly illustrate test environment elements and placement of each involved tool
within a deployment diagram
KPI Description
CPU utilization (%) Percentage of non idle CPU time over a specified interval
JBoss instances (Java process) CPU
% JBoss instances process usage
JVM Memory Total (KB) Provides the JVM total available memory
JBoss Requests in the Queue Specifies the number of requests in the queue
KPI Description
JBoss Available JDBC Connections The number of unused or available connections
JBoss JDBC Connections Created The total number of the created connections
JBoss JDBC Connections Destroyed The number of connections having been destroyed
- Specify Measurement tools for each layer, and identify relevant logging entries: The
table below lists the measurement tools that will be used for this lab:
Tool Function
Used to execute the load and performance tests scenarios
Apache JMeter and to monitor the test session execution: Transaction rate,
end user response time, etc.
- Define test cases with respect to customer requirements: write detailed test cases
workflow and Identify test data requirements
Below is the workflow that should be executed for the test case Search Applicants:
email or phone
number.
- Define the list of measurement tools: The measurement tools that will be used for this
test are:
o JMeter Used to launch the test and monitor its execution.
o AppDynamics based environment:
AppDynamics Agents: Used to collect applicative and resources
related metrics.
AppDynamics Controller: Used to host metrics gathered by
AppDynamics agents.
AppDynamics Dashboards: Used to monitor applicative and resources
related metrics during the test execution.
- Illustrate test environment and show the used instrumentation tool on each
component (instrumentation schemas)
Refer to the “Test environment” document.
Step 7: Consolidate all responses to the instructions above and write your L&P Test Design,
(use available PTD template).
4 IMPLEMENTATION
4.1 Objectives
Upon completion of this lab, you should be able to setup test environment and implement
design elements.
4.2 Exercises
4.2.1 Prerequisite
Before proceeding to next steps, ensure that the following points are checked:
- The design of test cases is accomplished
- The design of test scenarios is accomplished
- The load testing tool is installed locally
- Test environment machines are accessible
Step 2: Create the selected 3 test cases detailed in the previous section: To do it you have
to create 3 Thread groups by right-clicking on the “Test Plan” and add a new thread group:
Add > Threads (Users) > Thread Group
Step 3: Create a default HTTP Request and define the host Name and the Port number as
global variables
- user defined variables
- Default HTTP Request: Right click “Add -> Config Element -> HTTP Request
Defaults”
Step 5: Add a Runtime Controller and define the different steps as Transaction controllers
under each test case
- Runtime Controller
- Transaction controller
Step 11: Return back to HTTP(S) Test Script Recorder, click on the button "start" and select
the target controller for each step. go back and navigate in the reference application to
record the different requests related to each step
Step 12: After the recoding, stop the script recorder and try to expend the transaction steps
and to check the recoded requests.
Step 15: try to get the response of the applicant search using Regular Expression Extractor
Step 17: Add listeners in order to monitor requests and to get test results
Note that you can import external plugins to add new and rich listeners: you can for example
use the following: https://jmeter-plugins.org/wiki/GraphsGeneratorListener/
Once you are done with the above four steps, please proceed as follows:
Step 18: Configure and start monitoring agents
- Unzip the Java Agent zip file into <AppDynamics_Agent_HOME>
- Configure the agent to connect to Ayppdynamics controller
Update the file <AppDynamics_Agent_HOME>/conf/controller-info.xml with the
following properties:
<controller-host>10.66.12.9</controller-host>
<controller-port>8090</controller-port>
<account-access-key>9e515577-886d-4d2a-b839-b3d54f2e66c7</account-access-
key>
- Configure the agent with the application name, tier and node
Update the file <AppDynamics_Agent_HOME>/conf/controller-info.xml with the
following properties:
<application-name>adhocRefApp</application-name>
<tier-name>job-Applicant-Tier</tier-name>
<node-name>job-Applicant-Node</node-name>
- Configure Jboss server to start AppDynamics Agent
Add the following options to Jboss config file <JBoss_HOME>/bin/standalone.conf :
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,com.appdynamics,com.a
ppdynamics.,com.singularity,com.singularity.,org.jboss.logmanager,org.jboss.logman
ager."
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:/home/adcuser/adhoc-ref-
app/Jboss-Distribution/liferay-portal-6.1.1-ce-ga2/jboss-
7.1.1/modules/org/jboss/logmanager/main/jboss-logmanager-
1.2.2.GA.jar:/home/adcuser/adhoc-ref-app/Jboss-Distribution/liferay-portal-6.1.1-ce-
ga2/jboss-7.1.1/modules/org/jboss/logmanager/log4j/main/jboss-logmanager-log4j-
1.0.0.GA.jar:/home/adcuser/adhoc-ref-app/Jboss-Distribution/liferay-portal-6.1.1-ce-
ga2/jboss-7.1.1/modules/org/jboss/logmanager/log4j/main/log4j-1.2.16.jar"
JAVA_OPTS="$JAVA_OPTS -
Djava.util.logging.manager=org.jboss.logmanager.LogManager"
export JAVA_OPTS="$JAVA_OPTS -
javaagent:<AppDynamics_Agent_HOME>/javaagent.jar"
- Restart Jboss server
5.2 Exercises
5.2.1 Prerequisites
Before proceeding to next steps, ensure that the following points are checked:
- Test cases and test scenarios are setup on the Test Plan defined during the
previous section
- Performance test scripts are generated and validated
- Test environment machines are accessible
- Environment is properly instrumented
- The APM Tool is available and accessible
5.2.2 Task 1: Environment check and validation
The goal of the current task is to:
- Validate the test environment.
- Check the implemented scripts.
- Check if the instrumentation tools are working as expected.
- Check about the baseline metrics: Resource consumption in normal situation.
To do so, create and execute the single user scenario for each test case:
Step 1: Prepare session
- Refer to the model defined within step 5 of the section 3 and define test parameters
o Number of Users
o Ramp-up
o Test Duration
Note: to define the pacing, you should compute the define the wait time based on the
following formula:
Wait Time = Pacing - (Target Step Response Time + Sleep Time) * Nb Steps
Once the test is finished, collect all data gathered during the test:
- KPIs
- Log files
Step 7: Check results
- Check that there is no error related to the tests execution
- Check that monitoring tools are providing applicative and resources related metrics:
o You can see that there are stalled transactions that deal with Job Applications
Manager portlet. That confirms the response time behaviour.
o Now, open one transaction to see the transaction snapshot flow map: Al
illustrated in the following graph, You can see that 60 % of the transaction is
spent on calling the database.
o Now, click on the database node “LPORTAL-MYSQL DB” to see more details
about the DB call made during the transaction:
o Now, we can see the SQL query that takes the most part of the response
time. It matches the search query.
Step 9: Find the root cause of identified problem(s) using appropriate technique/tool(s)
- The search operation is made on the table job_Applicant.
- The first thing to check in case of slow SQL query is the existence of proper indexes.
- To check if the database is properly indexed, use the following command:
- SHOW INDEX FROM job_Applicant;
- We can see that the table is not properly indexed and this can be the cause of the high
response time.
5.2.3.3 Tuning
Step 10: Fix the problem(s) and restart the scenario execution
To confirm our hypothesis, we should add the proper indexes on the table job_Applicant and
re-run the same test.
Indexes should be added on the columns that are involved on the search criteria:
- create index IDX_JOB_APPLICANT_001 on job_Applicant
(applicantId,firstName,lastName,emailAddress);
Once re-executing the same scenario with the proper indexes, we can observe that the
response time is enhanced. The max value is 2.5 seconds instead of 5 seconds with the old
configuration.
5.2.4 Task 3: Execute & analyse a mixed scenario “Manage Applicants”
The scenario should be a mix of:
- "Remove Applicant" Average scenario
- “Update Applicant” Average scenario
Both scenarios should run on parallel.
5.2.4.1 Execute Scenario
Based on the scenario design, proceed to step 4 to 7 as described previously
- Check End User Response Time: We observe that the execution of some steps hangs
indefinitely. In fact, the steps “Update Applicant” and “Remove Applicant” are
executed almost only one time.
- Check Applicative metrics: Candidate should check the sequence diagrams that deal
with the step “Update Applicant” and “Remove Applicants”:
o Update Applicant:
o Remove Applicant:
Open Business Transactions statistics by clicking on the node “adhocRefApp > Business
Transactions” in AppDynamics Dashboard. You can see that there are 13 stalled
transactions that deal with Job Applications Manager portlet. That confirms the response
time behaviour.
By looking at the Events menu in the main AppDynamics Dashboard, notice that there are
some code problems.
Now, move to the events view by clicking on “Events” sub-menu in the left panel of the
dashboard.
Click on the first item and switch to Details tab. No you can see the details about the threads
that are locked
Step 9: Find the root cause of identified problem(s) using appropriate technique/tool(s)
Check the methods mentioned by the blocked threads. We can notice the existence of
synchronized block.
1. com.adhoc.referenceapp.jobapplications.manager.server.ApplicationsManagerServi
ceImpl.removeApplicants
synchronized (REMOVE_LOCK) {
try {
Thread.sleep(UPDATE_REMOVE_DELAY);
} catch (InterruptedException e) {
}
synchronized (UPDATE_LOCK) {
for (ApplicantDTO applicantDTO : applicantDTOList) {
2. com.adhoc.referenceapp.jobapplications.manager.server.ApplicationsManagerServi
ceImpl.updateApplicant
synchronized (UPDATE_LOCK) {
try {
Thread.sleep(UPDATE_REMOVE_DELAY);
} catch (InterruptedException e) {
}
synchronized (REMOVE_LOCK) {
// System.out.println("Updater Thread Holds lock on object UPDATE_LOCK");
try {
applicant = ApplicantLocalServiceUtil
.getApplicant(applicantDTO.getApplicantId());
applicant.setApplicantId(applicantDTO.getApplicantId());
5.2.4.3 Tuning
Step 10: Fix the problem(s) and restart the scenario execution
To correct the problem, proceed as following:
- Remove synchronized block as described previously
- Build and deploy modified portlet
- Re-run the same test