** The first response is an HTML file (expanded size is approxametly one megabyte, the compressed size that is going over the wire is about 200KB)

** The first response is an HTML file (expanded size is approxametly one megabyte, the compressed size that is going over the wire is about 200KB)

** The second response should be a .js or .javascript file with a size above 20KB, it contains the instructions for setting up the first user interface

** The second response should be a .js or .javascript file with a size above 20KB, it contains the instructions for setting up the first user interface

−

** You may have responses that are of type "unknown" as responses to the UICallBack requests (can also appear as .js)

+

** You may have responses that are of type "unknown" as responses to the UICallBack requests (can also appear as .js), in our example the third response

−

** All non Callback requests should have a response that contains some JavaScript instructions that do set some properties (e.g. w.setSpace of w.setItems in the example below)

+

** The fourth response and all consecutive "non-UICallback" requests should have a response that contains some JavaScript instructions that do set some properties (e.g. w.setSpace of w.setItems in the example below)

Revision as of 03:19, 26 September 2008

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

The first response is an HTML file (expanded size is approxametly one megabyte, the compressed size that is going over the wire is about 200KB)

The second response should be a .js or .javascript file with a size above 20KB, it contains the instructions for setting up the first user interface

You may have responses that are of type "unknown" as responses to the UICallBack requests (can also appear as .js), in our example the third response

The fourth response and all consecutive "non-UICallback" requests should have a response that contains some JavaScript instructions that do set some properties (e.g. w.setSpace of w.setItems in the example below)