Performance-Testing Flex Applications

Flex applications combine the best of desktop and Internet applications. As you consider your performance test requirements, keep in mind how Flex applications may be different from applications you have built in the past.

With an application that delivers the user interface in HTML—including JSP, ASP, ColdFusion, and PHP—the server does all of the processing. Users simply page back and forth to the server. This means your performance testing requirements include thinking through the key use cases for the application and simulating users on those key areas.

Flex applications are different. These encapsulated applications are downloaded and run on the desktop. They only go back to the server periodically to request or send data. For this reason, server loads reveal a very different profile. For example, it is entirely possible that a Flex application could download a data set and the user could work on that data set for hours without making another request of the server.

Chances are good that your Flex application will put a load on the server when the user logs in and requests the first data set. The next load will occur only sporadically as users work. Think about how to model that user load. For example, a typical user scenario might look like the following:

1. Log in.
2. Download initial data set of 100 records.
3. Work for four to five minutes.
4. Upload several records.
5. Download several records.
6. Return to Step 3 for five iterations.
7. Log off.

It's important to note that this may be very different from your user loads in HTML-based applications because they would constantly be paging back to the server for data.

When we look at modeling real user load, keep the different nature of Flex applications in mind to guide you in how to distribute real-life user loads.

Overview of Performance-Testing Tools

All the major automated-testing tools on the market allow you to simulate load on your server exactly as your user population will be using your Flex application. You create and control pools of users that simulate various use cases in random ways on your application, simulating the load your users will generate. The tools log and graph everything for you to show exactly how each of these virtual users fared as load increased on your server.

All the tools in this class work in a similar way. The basic workflow is as follows:

1. You create model scripts which represent use cases in your application. You do this simply by recording yourself using the application as a real user would.
2. You modify the scripts to provide the natural variability of your users, such as varying the login credentials, records opened, records saved, and other user actions. This step is important because it provides the real-world variability that keeps your application working hard and prevents you from missing performance problems because of caching at various layers on your server.
3. You define test data sets to be used by your scripts as you ramp up hundreds or thousands of simulated users executing your tests
4. You define profiles of load on your application. You might decide to have 20% of your users entering information slowly, 20% entering information very quickly, 40% looking up information, 10% producing reports, and 10% making account changes. The breakdowns and level of detail are entirely up to you.
5. You specify how to run the test. You control such things as the speed of ramping up user load, how fast each user executes the test, and whether there should be natural variability between users and sessions. Each tool provides different fine-grained control over this step.
6. You run your test and monitor your server resources. Here also, the various tools have differing levels of support for monitoring but they all provide a basic level of capability.

In the following sections, you'll learn how to record and modify the tests, as described in Steps 1, 2, and 3. The rest is up to your requirements for application testing.

Setting Up for Recording

After installing Segue Silk Performer and the Remoting add-in, setting up for recording and playing back scripts is easy.

Note: For more information on setting up, recording, and editing AMF scripts using Segue Silk Performer, see the Advanced Concepts documentation. Its chapter on testing Remoting AMF applications offers much detail not contained in this article.

1. Create a new project by giving it any name you choose.
2. In the Workflow - Outline Project dialog box, select the application type Web Browser > Flash Remoting (see Figure 1). You may not be familiar with the term Flash Remoting but this is the name of the stand-alone AMF server gateway. Flex users have Flash Remoting built into their Flex server to enable AMF.
3. Click OK. You are ready to record and play back scripts against your Flex AMF application.

Figure 1. Selecting Flash Remoting as the Flex application type

Page 2 of 4

Previous Page

Next Page