Load testing a Web Flow application is similar to load testing any other web application – we'll use a load testing tool to simulate increasing levels of concurrent client access in order to capture essential performance statistics.

With Web Flow there will be a couple of important considerations for the load test:

1. The load test must maintain independent “cookie storage area� so each client request can carry an independent HTTP session.
2. We need a mechanism for extracting the unique flow execution key from the initial response and use it to customize subsequent requests in the same flow session.

Apache JMeter is an open-source performance test tool that can satisfy both considerations.

For 1) we add an HTTP Cookie Manager element at the root of each Test Group exercising Web Flow functionality. The Cookie Manager ensures each simulated client request can have its own cookies independent of other client requests thus allowing the servlet container to track independent HTTP sessions through the jsessionid cookie.

For 2) we add a Regular Expression Extractor immediately after the HTTP Request Element that initiates the flow. The purpose of the Extractor is to parse the HTTP response, locate some text using a regular expression we provide, and to make that text available as a variable for subsequent HTTP Request elements to use. Here is a sample Regular Expression Extractor configuration:

Reference Name: flowExecutionKey
Regular Expression: name="_flowExecutionKey" value="(.*)"
Template: $1$
Match No.: 0


With the above configuration, we can now embed the variable ${flowExecutionKey}in subsequent HTTP Request Elements that are part of the same flow session.

Now let's use this to put Web Flow to a load test. To properly exercise representative Web Flow functionality I created a sample web flow application to mimic a 6-step shopping cart flow collecting user input for shipping address, shipping options, credit card, billing address, order confirmation, as well as an order summary at the end. Individual steps in this flow include data binding and validation, view states, action states, decision states, and sub-flow states – things we'd expect to find in a typical Web Flow application. The application however uses stubs instead of actual database access code to avoid including such numbers in the overall statistics. We'd like to focus on Web Flow alone for this test.

After building the application and creating the JMeter scripts I added an Aggregate Report element to record performance stats for tests with different load levels.

Using my Lenovo T60 dual-core laptop running Ubuntu and Apache Tomcat version 5.5 as the servlet container configured for a maximum of 150 concurrent connections I observed the following results:

Real load testing should be done on real hardware and based on real use cases. There is no substitute for that. However, we can derive certain conclusions from the above numbers.

The above numbers indicate that when exercising core Web Flow functionality throughput remains stable even as the number of concurrent users is significantly increased. The response time for 90% of users remains less than a second. The worst response time climbs as the load increases but that's not surprising considering the inadequate hardware used for testing.

Using the above technique you can load test your own Web Flow applications.

swf-shoppingcart-regexp.txt

Similar Posts

• Spring Framework 3.2 RC1: Spring MVC Test Framework
• Spring Web Flow 2.0 M4 – Feedback Requested
• Spring MVC 3.2 Preview: Techniques for Real-time Updates
• Introducing tc Server Developer Edition – with Spring Insight
• Spring Web Flow 2.2.0.M1 Released