Load testing Flex applications with NeoLoad

Consider a situation in which your company has developed a Flex 4.5 application that communicates with a server component such as BlazeDS or Adobe LiveCycle ES. You know that many potential issues (network settings, pool size, and poor design, among others) may result in unacceptable response times or an application failure when many users access the application simultaneously.

In situations like this, NeoLoad can help you ensure that your application will perform well under load. NeoLoad is a load testing software solution designed for web applications. It simulates a large number of users simultaneously interacting with the application and measures response times, errors, and other performance characteristics.

This tutorial describes how to load test the Inventory Management application included in the BlazeDS samples with NeoLoad. Although it does not cover all the processes and methodologies required for load testing in real-life situations, it provides a good introduction to the basics of load testing in a Flex environment.

The typical steps in a load test are:

1. Record a user interacting with the application
2. Parameterize the virtual user profile
3. Run the test
4. Analyze the results

This article will cover each of these steps. Be sure to download and install BlazeDS and NeoLoad (a 30-day evaluation version is available) before beginning.

In this section, you will record a user searching for a telephone in the inventory.

Create the NeoLoad project

1. Start NeoLoad and choose File > New.
2. Type InventoryManagement as the project name and click Finish.

NeoLoad will create the new project (see Figure 1).

Record a user profile

Follow these steps to record a user profile:

1. Choose Record > Start Recording.
2. Type SimpleUser as the virtual user profile name and click OK (see Figure 2).

3. In your browser, type the URL for the Inventory Management application. For example, type http://localhost.:8400/samples/inventory/index.html. Note that a period is required after "localhost" when recording with Internet Explorer.
4. Type N in the search field, and then select a phone in the list (see Figure 3).

5. Close the browser or choose Record > Stop Recording in NeoLoad to stop the recording.
6. In the Virtual Users tab, expand Virtual User Profiles > SimpleUser > CLIENT_PING and select getProductsByName (see Figure 4).

You can see that the AMF (binary protocol) call is decoded by NeoLoad and displayed in plain XML. The search criteria you typed while recording appears as a parameter of the getProductsByName operation: <String>N</String>.

In this section, you will learn how to parameterize your requests by replacing a recorded value with another appropriate value.
Why parameterize your requests? Generally speaking, requests must be parameterized for the two following reasons:

• Realistic testing. All your real users won't perform the same actions. You need to simulate users performing different actions on a variety of items otherwise your application will always be using cached data and the performance rating will be artificially high. Using varied data ensures that all layers of the application are properly tested. For typical applications, the cache levels are: application (server-side), database, operating system, and hard disk.
• Application identifiers. Consider a scenario in which a user first creates an item and then edits it. The editing panel usually refers to the edited item using an identifier that is submitted with the modifications. Simulating such behavior requires the identifier to be extracted from the server response after creation and then injected into the request that carries out the modification. (This process is beyond the scope of this tutorial.)

Without a load testing tool that can understand AMF it would be impossible to edit parameters, and thus impossible to parameterize a load testing script for any application that uses AMF to exchange data between the client and the server.  The ability to understand binary protocols is a key capability for load testing tools.

Create a new variable

This section describes how to create a variable that can be used to test different search criteria.

1. Choose Edit > Variables in NeoLoad.
2. Click New Variable.
3. Select the List item in the list.
4. Type search as the variable name.
5. Click the table header and rename the first column as Criteria.
6. Select For Each Virtual User as the Value Change Policy.
7. Type some values for the search criteria; for example, a, aa, b, bb, n, no. Click Add Value for each new value (see Figure 5).

8. Click OK to close the Create Variables dialog box.
9. Click OK to close the Edit Variables dialog box.

Using the variable to change the request parameters

Now you can use the newly created variable with several search criteria to parameterize the search request.

1. In the Virtual Users tab, expand Virtual User Profiles > SimpleUser > CLIENT_PING and select getProductsByName.
2. To edit the XML request, scroll down until you find <operation>getProductsByName</operation>. Under the <parameters> node, replace the recorded content <String>N</String> with <String>${search.criteria}</String> (see Figure 6).

3. Click Apply.

In this section, you will launch a test simulating several users accessing the server.

Set up the scenario

1. Click Runtime (see Figure 7).

2. Set the duration of the test. Use 10 minutes, for example (see Figure 8).

3. To set the load variation policy, select the Ramp Up option. Start with one user initially, and increment by one new user each minute (see Figure 9). Select Maximum Number Of Users and type 10 as the maximum number.

Note: Generating more than 10 simultaneous users requires a commercial license for NeoLoad.

Launch and supervise the test

1. To begin the test, Click Start (see Figure 10).

2. Use the different tabs to display real-time information on the test as it executes (see Figure 11).

3. Wait for the test to finish or click Stop to terminate it.

At the end of the test, NeoLoad automatically switches to Results view and displays a report with key graphs and statistics (see Figure 12) so you can quickly see if your application handled the load. The main items to check are:

• Errors. If you see any errors, analyze the error type (for example, network error, server internal error 500, and so on) and details to identify the cause. Performance monitors can help in this process.
•  Response times. Check to see if the response times for your requests or business transactions meet your performance requirements (for example, you may want to ensure that each user’s login time is less than five seconds).

NeoLoad provides graph tools, statistics, and error reports to help you check results against your performance requirements and search for the causes of any bottlenecks.

Now that you have learned the basics of load testing a Flex application, you can get more information on the Neotys website:

• General information
• Demos and technical information on load testing Flex applications
• Tutorial on Adobe Flex/AMF: Handling polling and streaming
• LiveCycle Data Services ES monitoring.