Revision as of 03:14, 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
  • 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)
  • 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)

org.eclipse.swt.EventUtil.suspendEventHandling();
var req = org.eclipse.swt.Request.getInstance();req.setRequestCounter( "7" );
var wm = org.eclipse.swt.WidgetManager.getInstance();
var w = wm.findWidgetById( "w44" );
w.setSpace( 0, 796, 19, 20 );
var w = wm.findWidgetById( "w81" );
w.setItems( [ "View I / Locate in browser view", "View I / Root", "View I / null"]);
qx.ui.core.Widget.flushGlobalQueues();
org.eclipse.swt.EventUtil.resumeEventHandling();

• • if all requests contain only like this, the test is not properly executed

org.eclipse.swt.Request.getInstance().send();
org.eclipse.swt.Request.getInstance().enableUICallBack( "rap",
"custom_service_handler",
"org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler" );