Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "RAP/LoadTesting"
(→Recording a test) |
(→Running a test) |
||
| Line 18: | Line 18: | ||
==Running a test== | ==Running a test== | ||
| − | * When running the tests with multiple threads you need to include an HTTP Cookie Manager (Please note that there is a bug in JMeter 2.3.1 for clearing cookies for multiple runs / iterations; see [http://markmail.org/message/bis6om3wnpqtqin5]) | + | * When running the tests with multiple threads you need to include an HTTP Cookie Manager (Please note that there is a bug in JMeter 2.3.1 for clearing cookies for multiple runs / iterations; please use either JMeter 2.3.0 or 2.3.2 see [http://markmail.org/message/bis6om3wnpqtqin5]) |
| + | |||
| + | This is how the test plan should look like: | ||
| + | |||
| + | [[Image:JMeterCookieManager.png]] | ||
| + | |||
| + | If cookies are not working every request will create a new session, this is not what we want to test (and leads to massive server load). | ||
| + | |||
| + | Also note the Gaussian Timer that has been added. A timer adds wait time between the requests, leading to a better approximation of a real users behaviour. If you don't add a timer you are putting a much higher load on the server, as every response is immediately followed by the next request, something a real user is not able to do. | ||
| + | |||
| + | |||
| + | This is how we check if the playback of the session is working. | ||
| + | * Start testing with only ONE session and two loops (configured in the Thread Group) | ||
| + | * Add a "Save Responses" post-processor | ||
| + | * [[Image:JMeterSaveResponses.png]] | ||
| + | * Examine the response files, the patter should look like this | ||
Revision as of 02:59, 26 September 2008
| RAP wiki home | RAP project home |
DRAFT Load testing / stress testing of RAP applications
This is a brief example on how to do load testing / stress testing of RAP applications with JMeter.
Recording a test
JMeter allows to record tests by adding a proxy to your browser and simply record the user interactions with the server. This Introduction (PDF) is very useful for getting started with JMeter.
This is a sample proxy configuration that you can load into JMeter 2.3.2.
There are a couple of hints that you need to take into account for recording RAP application tests:
- Re-Start the browser before recording a test (or make otherwise sure that you are starting with a NEW session, e.g. by deleting the cookies)
- After recording your test you need to eliminate duplicate requests to the UICallbackServiceHandler (so that there are never two or more consecutive requests of this type). The callback requests do not have the ?nocache directive as url parameter.
- WRONG:
- RIGHT:
- It does not matter which callback request(s) you delete, as long as exactly one is remaining
Running a test
- When running the tests with multiple threads you need to include an HTTP Cookie Manager (Please note that there is a bug in JMeter 2.3.1 for clearing cookies for multiple runs / iterations; please use either JMeter 2.3.0 or 2.3.2 see [1])
This is how the test plan should look like:
If cookies are not working every request will create a new session, this is not what we want to test (and leads to massive server load).
Also note the Gaussian Timer that has been added. A timer adds wait time between the requests, leading to a better approximation of a real users behaviour. If you don't add a timer you are putting a much higher load on the server, as every response is immediately followed by the next request, something a real user is not able to do.
This is how we check if the playback of the session is working.
- Start testing with only ONE session and two loops (configured in the Thread Group)
- Add a "Save Responses" post-processor
-
- Examine the response files, the patter should look like this
