A couple weeks ago I
blogged how to configure Apache JMeter for testing Oracle's ADF. This week to complete the set, I'll post my findings on stress testing Oracle's Application Express (Apex) with JMeter . Both posts are related to an earlier
post on how to record sessions in JMeter that are essential reading to understand what I've specified here.
A Small CaveatPlease note this particular post is the result of my rather limited testing of JMeter with Apex. I'm not an Apex expert, and I haven't used it for over 2 years in any development project. The implication for this post is I might not have discovered absolutely everything that needs to be done to set up JMeter for stress testing Apex in every considerably use case.
If you discover a problem, and hopefully a fix, to assist other readers it would be great if you could post your comments to this blog to assist those next readers please.
Yet Another Small CaveatFor those who read my ADF post, you'll find much of the text in this post similar. I'm mindful I have readers leaping into this post from Google without having read anything earlier, so I'm guessing it's important I give them the same spool. Apologies for repeating myself.
Not a Caveat, But My ThanksI need to express my thanks to both
Penny Cookson and
Patrick Wolf with their assistance in getting this post together. Both obviously have a huge amount of experience with Apex and their thoughts and guidance were appreciated.
IntroductionWhen considering using JMeter for Oracle Application Express applications there are additional JMeter configuration steps required beyond that detailed in the original post. Apex similar to most web applications uses Cookies, and you can use JMeter's HTTP Cookie Manager to correctly handle the cookie. However Apex also makes use of a number of parameters passed as HTTP POST parameters and URL parameters. On running an Apex application you'll often see URL parameters including the session ID, and embedded within the HTTP bodies variables such as p_instance, p_vt01, p_arg_names and more, used by Apex to coordinate state with the browser session. In order for JMeter to simulate multiple user sessions it needs to be correctly configured to handle these too, capturing and carrying the unique values for each session in the load test.
The following post lists the additional configurations required for JMeter beyond those described in the original post. As noted in the original post the easiest way to setup your JMeter Test Plan is to record an existing Apex session through JMeter's HTTP Proxy Server and I haven't bothered to reiterate those instructions here. In turn I've taken no effort to explain the JMeter features we're utilizing to do this; if you want to learn about the relevant JMeter features consult the JMeter
User Manual.
These instructions were created against the Apex version 3.2.1.00.10 included with the latest 11gR2 Oracle database release on Windows. Presumably in the future, possibly Apex v4, it will change its HTTP mechanisms, resulting in you having to carefully check this post's instructions against the future Apex version.
JMeter Apex Required ConfigurationsThe following lists the additional objects and their settings required within JMeter. You need only create one of each for each Thread Group but I'll agree there does seem to be a lot of them. The end result will look something like this:
a) HTTP Cookie Manager
Create via Test Plan -> Thread Group -> Right Click -> Add -> Config Element -> HTTP Cookie Manager
| Name: | HTTP Cookie Manager |
| Clear cookies each iteration: | Selected |
In my original JMeter
post, you'll see in the comments from
Manolis Nikiforakis, he suggests the Cookie policy should be set to "compatible". In my own testing that didn't seem to work, so I used rfc2965 instead. See what works for you.
b) User Defined Variables
Create via Test Plan -> Thread Group -> Right Click -> Add -> Config Element -> User Defined Variables
| Name: | User Defined Variables Variables |
| Variable Name: | sessionId |
| Variable Name: | p_flow_id |
| Variable Name: | p_flow_step_id |
| Variable Name: | p_instance |
| Variable Name: | p_page_submission_id |
| Variable Name: | p_request |
| Variable Name: | p_md5_checksum |
| Variable Name: | p_arg_values |
| Variable Name: | p_arg_names01...XXX |
| Variable Name: | p_arg_names01name...XXX |
| Variable Name: | p_arg_names01value |
| Variable Name: | success_msg |
Above where you see p_arg_names01...XXX and p_arg_names01name...XXX, what I'm implying here is you need to define as many as these as there are submittable fields on your Apex web pages. In the picture you can see I've defined a set of 10. How many do you need to create, well, you need to carefully look at the session requests you've recorded in JDev and identify the maximum number of fields like p_v01, p_t02 etc. If you're not familiar with what I'm describing here, read on and hopefully it'll become more apparent.
c) sessionId Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | sessionId Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | sessionId |
| Regular Expression: | f?p=([0-9]{1,3}):([0-9]{1,3}):([0-9]{16}): |
| Template: | $3$ |
| Match No.: | 1 |
| Default Value: | n/a |
d) p_flow_id Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_flow_id Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_flow_id |
| Regular Expression: | <input type="hidden" name="p_flow_id" value="(.+?)" id="pFlowId" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
e) p_flow_step_id Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_flow_step_id Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_flow_step_id |
| Regular Expression: | <input type="hidden" name="p_flow_step_id" value="(.+?)" id="pFlowStepId" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
f) p_instance Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_instance Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_instance |
| Regular Expression: | <input type="hidden" name="p_instance" value="(.+?)" id="pInstance" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
g) p_page_submission_id Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_page_submission_id Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_page_submission_id |
| Regular Expression: | <input type="hidden" name="p_page_submission_id" value="(.+?)" id="pPageSubmissionId" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
h) p_request Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_request Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_request |
| Regular Expression: | <input type="hidden" name="p_request" value="(.+?)" id="pRequest" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
It's possible this extractor isn't needed, see why in the following descriptions. However I've included it for completeness.
i) p_md5_checksum Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_md5_checksum Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_md5_checksum |
| Regular Expression: | <input type="hidden" name="p_md5_checksum" value="(.+?)" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
It's possible this isn't required. In my mini Apex application I never saw the checksum populated. Potentially it may be in yours so I've included it for completeness here.
j) p_arg_values Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_arg_values Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_arg_values |
| Regular Expression: | <input type="hidden" name="p_arg_values" value="(.+?)" /> |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
h) p_arg_names01..XX Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_arg_names01...XX Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_arg_names01..XX |
| Regular Expression: | <input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)" |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
As described in the User Variables section, you'll need as many as these as the maximum amount of fields you have in any of your Apex pages. In the above table the Name and Reference Name should not include ..XX, that's just a notation to mean you need to create many of them. Look to the picture to see exactly what you define for the first.
k) p_arg_names01name..XX Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_arg_names01...XX Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_arg_names01name..XX |
| Regular Expression: | <input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)" |
| Template: | $3$ |
| Match No.: | 1 |
| Default Value: | n/a |
Again as per the last extractor, you'll need as many as these as the maximum amount of fields you have in any of your Apex pages. In the above table the Name and Reference Name should not include ..XX, that's just a notation to mean you need to create many of them. Look to the picture to see exactly what you define for the first.
l) p_arg_names01value Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | p_arg_names01value Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | p_arg_names01value |
| Regular Expression: | <input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)" value="(.+?)" id="P2_BOOKING_NO" /> |
| Template: | $4$ |
| Match No.: | 1 |
| Default Value: | n/a |
In your application if you have sequence number fields that are prepopulated from a database sequence number and hidden from the user, you need to include an extractor for each. In this example we're grabbing a hidden P2_BOOKING_NO field.
l) success_msg Regular Expression Extractor
Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor
| Name: | success_msg Regular Expression Extractor |
| Response Field to Check: | Body |
| Reference Name: | success_msg |
| Regular Expression: | success_msg=(Action%20Processed.%2F[A-F0-9]{32,33}%2F) |
| Template: | $1$ |
| Match No.: | 1 |
| Default Value: | n/a |
It's possible in this extractor the length of the hex regular expression of 32-33 chars could be to limited.
Recorded HTTP Request ChangesAfter recording an Apex session in JMeter, and setting up the variables above, you'll note in the recorded HTTP Requests numerous references to the same named variables as HTTP parameters. Yet the recorded HTTP Requests include the parameters' values for the recorded session, which simply won't work when we replay the session as the values will have changed.
It is therefore necessary to identify all locations where the parameters exist in the recorded session HTTP Requests and substitute references to your variables.
a) HTTP Request – Parameters – sessionId
For any HTTP Request that has the parameter "p", where the value looks something like:
102:1: 1438937389458569:::::
The third value must be replaced with
102:1: ${sessionId}:::::
If you see a "p" value that looks something like this:
102:1::::::
...don't modify it.
b) HTTP request – Parameters – for any of the following parameters we need to change their values to the following expressions:
p_flow_id -> ${p_flow_id}
p_flow_step_id -> ${p_flow_step_id}
p_instance -> ${p_instance}
p_page_submission_id -> ${p_page_submission_id}
p_arg_names -> ${p_arg_names}
p_v01...p_vXX -> ${p_arg_names01..XX}
p_t01...p_vXX --> ${p_arg_names01..XX}
...as demonstrated in the following picture:
Then in addition for each p_v01..XX and p_t01..XX fields you'll need to replace the actual parameter names, such that:
p_v01..XX -> ${p_arg_names01name..XX}
p_t01..XX -> ${p_arg_names01name..XX}
...ditto for every parameter name, as demonstrated in the following picture:
You'll note we haven't bothered to do anything with the p_request and p_md5_checksum fields. I'm still not overly convinced we need to, so I've included them in the User Variables and Regular Expression Extractors, but haven't done any more with them at this stage.
c) HTTP request – Parameter – success_msg
For the success_msg parameter, replace its value with ${success_msg}, and ensure Encoding is turned off:
AssertionsOnce you've completed the above setup and want to run your load test via JMeter, it is important to see that the test is working correctly. One way to do this is to create a View Results Tree (Test Plan -> Thread Group -> Right Click -> Add -> Listener -> View Results Tree) that allows you to inspect the response of each HTTP Request. If you then see HTTP Request responses in red this indicates a HTTP error code response (!= 200). However it's also necessary to inspect each response even if they are green to see if there's a valid response returned carrying an error message. There is definitely a small knack to differentiating between the different type of failures in an Apex application, which you'll become familiar with on some experience.
In order to save you having to look for the same problems for each test-run, you can create a Response Assertion (Test Plan -> Thread Group -> Add -> Assertions -> Response Assertion) to look for specific errors in the responses. To set this up:
| Which Samples to Test: | Main Sample Only |
| Response Field to Test: | Text Response |
| Pattern Matching Rules: | Contains |
| Not: | Selected |
| Patterns to Test #1: | The error string you're looking for |
Sample JMeter fileReaders can download a sample JMeter JMX file for Apex
here with the configurations already setup.
Finishing CommentAs I mentioned much earlier in this post, this post really constitutes my research to date in stress testing Apex with JMeter, and doesn't necessarily cover everything you need to do. Ultimately my goal, like other posts on this blog is to share the spark of inspiration such that you can take the ideas and run with them to form a complete solution yourself. Without a doubt because of the length of this post I'll have a typo or have missed something, so again follow up comments would be appreciated to help the next reader please.
Good luck.
