JMeter first steps for solving/verifying a RAC performance problem

What is JMeter ?

  • Jmeter is a s functional testing tool for a web application, file server, web server and even database
  • Is easy to configure and provides all needed tools to run HTTP load tests against any WebServer

Download and Install JMeter

Download Jmeter 2.13 from
 $ mkdir JMETER
 $ unzip
 $ pwd
 $ chmod 755 jmeter
 $ jmeter
--> GUI should be started !


First JMeter Project

Add Users
Edit > Threads(User) -> Thread Group

Add HTTP Request
Thread Group [ RC ] -> Add -> Sampler -> HTTP request
 Server Name : localhost   
 Port Number : 8180   
 Path        : /WFJPA2EL-1.0

Add Listener to display HTTP traffic
Thread Group [ RC ] -> Add -> Listener -> View Results Tree

Now Press Start and verify the HTTP traffic
View Result Tree -> Traffic -> Click on a Single HTTP request
There a 3 Viewing Options to display the test results 
 - Sampler results 
 - Request
 - Response data  

Details on above Viewing Option
- Sampler Results 
  Thread Name: Thread Group 1-1
  Sample Start: 2015-06-09 08:30:58 CEST
  Load time: 29
  Connect Time: 4
  Latency: 6
  Size in bytes: 4910
  Headers size in bytes: 454
  Body size in bytes: 4456
  Sample Count: 1
  Error Count: 0
  Response code: 200
  Response message: OK

  Response headers:
   HTTP/1.1 200 OK
   Connection: keep-alive
   X-Powered-By: Undertow/1
   Set-Cookie: JSESSIONID=6RuYgEBp_dbe0VnE2S_8FWk2.wls1; path=/WFJPA2EL-1.0
   Server: WildFly/8
   Content-Type: text/html;charset=UTF-8
   Content-Length: 4456
   Date: Tue, 09 Jun 2015 06:30:58 GMT

  HTTPSampleResult fields:
   ContentType: text/html;charset=UTF-8
   DataEncoding: UTF-8

- Request data
  GET http://localhost:8180/WFJPA2EL-1.0/
  [no cookies]
  Request Headers:
  Connection: keep-alive
  Host: localhost:8180
  User-Agent: Apache-HttpClient/4.2.6 (java 1.5)
  Thread Group [ RC ] -> Add -> Sampler -> HTTP request

- Response Data [ The HTML document ! ]
  <?xml version='1.0' encoding='UTF-8' ?>
  <!DOCTYPE html>
  <html xmlns=""><head id="j_idt2">
        <title>Testing RAC - J2EE JPA2 API! </title>
         .BGImage{ background-image: url("resources/images/1920x1200_night.png"); }
        </style></head><body class="BGImage"><table>

Add HTTP Cookie Manager and HTTP Cache Manager

Thread Group [ RC ] -> Add -> Config Element -> HTTP Cookie Manager 
Thread Group [ RC ] -> Add -> Config Element -> HTTP Cache Manager 
HTTP Cache Manager  -> simulates WEB Browser Caching
HTTP Cookie Manager -> simulates Browser Cookie 
 -> Click on HTTP cookie manager -> Uncheck Clear Coookies  each Iteration
With an enable HTTP Cookie Manager the request should look like  
  GET http://localhost:8180/WFJPA2EL-1.0/
  Cookie Data:
Without an HTTP Cookie Manager the Request looks like: 
  GET http://localhost:8180/WFJPA2EL-1.0/
  [no cookies]

Recording a User Script With a Browser

For inital testing modify Thread Group : 
  Number of Threads ( user ) : 1
  Loop Count                 : 1

Use the Recording template 
File -> Templates -> Recording 
This creates a Test Plan with following major elements
 - User Defined Variables
 - HTTP Request Defaults
 - HTTP Cookie Manager
 - Thread Group
   - Recording Controller
   - View Results Tree
 - WorkBench
   - HTTP(S) Test Script Recorder   
   - View Results Tree  

Verify HTTP(S) Test Script Recorder settings  and start the Recorder 
--> Global Settings for Proxy Port :  8888
    Go to the end of HTTP(S) Test Script Recorder Page and press  << Start >>

Prepare your WEBapplication by modify the Firefox Proxy Configuration
Edit -> Preferences -> Advanced -> Network -> Settings -> Manuals Proxy Configuration 
  HTTP Proxy : localhost  Port : 8888 
  Remove Entries NO PROXY entries like  : localhost,

Record the Session 
Start the initial HTTP GET request
$ firefox http://localhost:8180/WFJPA2EL-1.0/  
Now Press your GUI buttons  to create the HTTP Post requests !

Review Recorded HTTP traffic under 
Thread Group -> Recording Controller ->
   45 /WFJPA2EL-1.0
   45 /WFJPA2EL-1.0                    GET 
   46 /WFJPA2EL-1.0/                   GET
   47 /WFJPA2EL-1.0/faces/index.xhtml  POST
   48 /WFJPA2EL-1.0/faces/index.xhtml  POST
   49 /WFJPA2EL-1.0/faces/index.xhtml  POST
   50 /WFJPA2EL-1.0/faces/index.xhtml  POST
   51 /WFJPA2EL-1.0/faces/index.xhtml  GET

Now Replay the Recorded Session by pressing START and check the  newly filled View Results Tree
-> All POST request are failing with 
   Error Count: 1
   Response code: 500
   Response message: Internal Server Error

The HTTP GET request returns 
   j_id1:javax.faces.ViewState:0" value="-3761271259220317840:-5309836328462799600" 


wheras the POST request sending back the old recorded ViewState variable   


As you can see the ViewState variable returned from the HTTP GET request is different than the 
ViewState variable sent in the subsequent HTTP POST request. This is the root cause for getting 
Response code: 500 errors 

Fix :
We need to extract the ViewState from the first GET request into a variable and 
arm our subsequent HTTP POST with that variable .

Step 1: Extract the hidden Field ViewState into a Variable 
First Add a Debug Sampler 
Thread Group -> Add -> Sampler -> Debug Sampler 

Locate the ViewState value returned from the first HTTP GET request
Thread Group -> View  Result Tree [ Use the same HTTP requst ID as found in the Recording Controller output
View Result Tree     :  45 /WFJPA2EL-1.0/
Recording Controller :  45 /WFJPA2EL-1.0/

Copy  from View Result Tree ( Use <ctrl>C and <ctrl>V  for copy and paste ) the following Line :
"j_id1:javax.faces.ViewState:0" value="-4364374341049834252:-7433662177008040460" autocomplete="off"

Add regular Expression to extrace ViewState variable - 
Go the first HTTP GET request [ request 31 ]  
  Recording Controller ->  RC HTTP GET request -> Add -> Post Processors -> Regular Expression Extractor 

Reference Name     : jsfViewState 
Regular Expression : input type="hidden" name="javax.faces.ViewState" id="j_id1:javax.faces.ViewState:0" value="(.+?)" autocomplete
Template           : $1$

Note we changed  in the Regular Expression Extractor :
  ViewState:0" value="-4364374341049834252:-7433662177008040460" 
  ViewState:0" value="(.+?)"


Now Replay and verify that Debug Sampler successfully extract the jsfViewState parameter 
View Result Tree -> Debug Sampler ->  Response Data 
jsfViewState_g0=input type="hidden" name="javax.faces.ViewState" id="j_id1:javax.faces.ViewState:0" value="8326703641583194307:-77748042595564357" autocomplete
-> jsfViewState variable is succesfully extracted  from the HTTP GET request 

Step 2 : Replace all related POST request replace the ViewState Parameter with our  extracted  ${jsfViewState}  Variable 
Goto Recording Controller click on the first POST Request wich is in our case : 32 /WFJPA2EL-1.0/faces/index.xhtml
Scroll Down the Parameter Box and locate 
javax.faces.ViewState    7488737670588160729:2714299608714531806    true    true 
Replace the value field 7488737670588160729:2714299608714531806    with our view state variable : ${jsfViewState}  
The complete record should now look like ; 


-> Note be careful and remove any spaces behind ${jsfViewState}     declaration 
Repeat this step for all subsequent HTTP POST requests .
Rerun the recorded session - all HTTP operation should be flagged green  


The last HTTP GET request reports in the Sampler Box : 
Thread Name: Thread Group 1-1
Sample Start: 2015-06-18 19:42:35 CEST
Load time: 153
Connect Time: 0
Latency: 136
Size in bytes: 54033
Headers size in bytes: 0
Body size in bytes: 0
Sample Count: 1
Error Count: 0
Response code: 200
Response message: Number of samples in transaction : 5, number of failing samples : 0

Working with Assertions

Duration  Assertion
First lets have a look as the current statistics for out HTTP Post request by looking on out Summary Report  
                                      Samples  Avg     Min      Max   Std. DEv Error   Throughput       KB/s       
16 /WFJPA2EL-1.0/faces/index.xhtml    3    17    12    28    7.318    0.0        18.98    96.11     
-> We don't have any errors and the Average Response Time is 12 ms 

Rerun test again and check  Summary Report  
Add a Duration Assertion for the above HTTP Post with : 12 ms 
                                      Samples  Avg     Min      Max   Std. DEv Error          
176 /WFJPA2EL-1.0/faces/index.xhtml    15    13    11    28    4.02    0.066
-> 6,6 % of our requests shown some ERRORS 

View Test Results
Double click on the red marked Request 
  Assertion error: false
  Assertion failure: true
  Assertion failure message: The operation lasted too long: It took 13 milliseconds, but should not have lasted longer than 12 milliseconds.
-> Here we get Details about our failed Request

Add a response Assertion to a HTTP POST 
Recording Controller -> RC HTTP POST -> Add Assertions -> Response Assertion 


In this HTTP response we expect to find following test pattern :
   -> Suspend Transaction - Status: SUSPEND - Salary:1500

Reviewing a failed Response Assertion :



First Performance Tests

For last testing we are  heavy business transaction doing the following :
- HTTP Request1      : Request the inital page via HTTP GET request
- HTTP POST Request2: Uses  a HTTP post request to
   - Start a JTA transaction ( Not JTA transaction are always XA transactuons
   - Run JPA flush [ == Insert a new db record ]
   - Suspend the JTA transaction using the JEE TransactionManager API
   - Add JTA transaction object, Entity Manager object to our HTTPSession Object
- HTTP POST Request3: Uses  a HTTP post request to
  - retrieve JTA transaction object and Entity Manager object from our HTTPSession Object
  - Resume the Transaction and update the record
  - Commit the record -  in case of any errors rollback the transacton
  - Cleanup HTTP session object , clear the Entity Manager
- HTTP Request4: Uses  a HTTP post request to
- Invalidate the HTTP session

For performance  testing we modify  our Thread Group :
Number of Threads ( user ) : 5
Loop Count                 : 1000
This JMETER session will run 5.000 Business Transactions
Note: Disable all Listeners for Throughput / Performance Testing as listeners are very CPU and
     Memory intensive .
-> For the inital performance test we will run only using the Summary report


Findings :
- We are running 5.000 Transactions with a throughtput of 200 HTTP request per second
- About 0.18 % of our HTTP requests are failing
- The average duration of our HTTP post are between 30  and 59 ms

As we get some errors we will add the  View Results Tree.
Because we are in a testing phase where we print errors and runtine information to the User 
screen the HTML will give us an easy way to get details about the error


Some Deatails about Listeners

Useful Listeners
  - Summary Report
  - Repsonse Time Graph
  - View Results in Table
  - View Results Tree

Note Disable all Listeners for Throughput / Performance Testing as listeners
are very CPU and Memory  time intensive

Real Testing with RAC, JMeter and Virtaulbox

14:23:21.294 Calling  getRacInfo() in progress ... 
14:23:21.294 Hibernate Version: 4.3.7.Final
14:23:21.294 Driver Name             : Oracle JDBC driver
14:23:21.294 Driver Version          :
14:23:21.294 Database Product Version: Oracle Database 12c Enterprise Edition Release - 64bit Production
             With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
             Advanced Analytics and Real Application Testing options
14:23:21.512 DB Name:  BANKA
14:23:21.512 1. Instance Name: bankA_3 - Host: - Pooled XA Connections: 32
14:23:21.513 2. Instance Name: bankA_1 - Host: - Pooled XA Connections: 31
14:23:21.513 Leaving getRacInfo() without Exceptions !

All tests run on a single s

Test Scenario
- 10 Threads running a complex Transaction using suspend and resume 1000x
- This translates to running 50.000 Transactions.
Testcase Details
 - Using 2 datasources having MAX Connections set to 50  
     Datasource 1 is a JPA datasource and is used to operate on our JPA Entities
     Datasource 2 simulates a Normal datasource [ used as a tracking tool ]
 - Even we need to rollback our global transaction we need to write some log information before the ROLLBACK 
 - The HTTP mentioned mentioned below are resp 
 - HTTP POST request 1 : adds an Entity to the HTTP session object
 - HTTP POST request 2 : Starts the transaction running tm.begin()
                         Calls em.flush() to store that record in our RAC DB asap
                         Supspend the XA Transaction running tm.suspend()
                         Logs some data via JDBC API and COMMITs that data [ this is possible as we have suspended our XA transaction ]
                         Resume the transaction using tm.resume()
                         Update our record running em.merge()
                         Commit the data running tm.commit()
                         Logs some data via JDBC API and COMMITs that data

Configuration and Test details 
Host System: 
 - Windows 8.1 
 - CPU i7-4710-HQ 2,5 GHz - 1 socket, 4 Physical CPus, 8 Logical CPUs - 16 Gbyte RAM 
  - VirtualBox System I   running : OEL 6.6, Wildfly 8.2 , 10 Threads ( running Jmeter )
  - VirtualBox System II  running : OEL 6.6, Oracle RAC , Instance bankA1 
  - VirtualBox System III running : OEL 6.6, Oracle RAC , Instance bankA2 
  - All VirtualBox System are configured to occupy a single physical CPU only 

What we exe expecting: 
- The testcase is CPU bound (  very little DB actions) 
- Our Host system running the Jmeter Threads should occupy  about 100 % of our CPU.

Single  Core Testing - Verifiy CPU details on our JMeter VBox System 

Guest System [ OEL 6.6 ] details :
[oracle@wls1 Desktop]$ nproc
[oracle@wls1 Desktop]$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               2496.669
BogoMIPS:              4993.33
L1d cache:             32K
L1d cache:             32K
L2d cache:             6144K
NUMA node0 CPU(s):     0

-> Only a Single Physical CPU is active for our Virtualbox System running 
the Jmeter tests !

Jmeter test results :

TaskManager Test results :

Resource Manager test results:
Test Summary:
 - No all CPU ticks available are used for our testing 
 - This leads to a low TPS rate of 19.5 annd is far away from a real stress test

Assumption : We assume that the VirtualBox System running the JMeter threads is limiting factor !

-> Let's add  additonal CPU Power to the Virtualbos System 

Change VBox Configuration  to use all 4 physical CPUs: 

Verify transaction rate using JMeter Output: 

Verify CPU Usage via Task Manager : 

Test Summary after changing Virtualbox Setup to  use all phy. CPUs
- Transaction rate increased from 19,6 TPS to 51,5 TPS
- All CPUs are running at 100 % speed 

Reference :

One thought on “JMeter first steps for solving/verifying a RAC performance problem”

Leave a Reply

Your email address will not be published. Required fields are marked *