Accessibility

Table of Contents

  1. Introduction
  2. Exploring Caching in the Flex Presentation Server
  3. Modifying the flex-config.xml File Configuration Settings
  4. Accessing the Flex Data Services
  5. Using the JSP Tag Library
  6. Precompiling MXML Pages
  7. Considering Your Deployment Options
  8. Load Testing Your Flex Application
  9. What the Future Holds...

Flex Application Performance: Tips and Techniques for Improving Flex Server Performance

Load Testing Your Flex Application

The performance of your Flex application is highly dependent on your existing applications and infrastructure. For example, the Flex application server and data services may be able to sustain several hundred requests per second. However, if your web service or remote object can only sustain 35 requests per second, your web service becomes the bottleneck and hinders scalability. This is why you must test each independent tier of your application on its own. The following sections explore how you can load test your Flex application. (See also the "Performance Tuning and Profiling Your Own Flex Application" section in the article, "Flex Application Performance: Tips and Techniques to Improving Client Application Performance.")

Load-Testing Tools

First, load test each of your data services independent of the Flex proxies. If you have a web service or an XML feed from a servlet, use a load-test tool to gauge the maximum number of requests per second that it can sustain. Second, run the same test through the Flex proxy, because all traffic is sent from the Flash client to the proxy, and the proxy, in turn, sends the request to your web service or HTTP feed.

You can choose among several load-testing tools, ranging from free tools to tools that cost tens of thousands of dollars. During the development and staging phases, a free tool works just fine for load testing individual services (such as web services, remote objects, or XML feeds). Some free load-testing tools are:

However, to load test a finished application and randomize request data, use one of the following commercial load-testing tools:

Load Testing Sample Scenarios

During development, test each of the services that your Flex application consumes. This can be as simple as using one of the free tools listed previously to record interaction between the Flash client and the server and playing back the recorded request/response under a multiuser scenario. This section describes several scenarios using different approaches and data services.

Scenario 1

A common approach is to use a JSP or servlet that exposes XML to the Flex application and is invoked using the <mx:HTTPService> tag in Flex. After building a portion of the application that consumes this XML feed, load test to ensure the back-end service can sustain the production load. Since most development systems do not provide production horsepower, use a staging environment that mirrors the production system. Using the staging system and a testing tool, you can record the traffic that occurs between the browser and server. The testing tool records the traffic and can play it back using multiple threads (or users) to simulate a production load. It is important that at this stage that you only test the data services, not the loading of the SWF file or the other services that Flex provides. Delete the other requests from the recorded script. The following snippet shows requests from a sample script recorded in Microsoft WAS:

GET /sharedapps/xmltest/WeeklyReport.mxml
 GET /flex-internal?action=js
 GET /sharedapps/xmltest/WeeklyReport.mxml.swf
 GET /flex-internal/history/history.html
POST /flex/flashproxy 
(post data transport=http%2Dget&target=http%3A%2F%2F192%2E169%2E1%2E24%3A8100%2Fsharedapps%2Fxmltest%2Fxml%2Ejsp) 
 GET /flex-internal?action=swf

Delete all requests except POST /flex/flashproxy to focus on load testing only the XML feed. Later, before you go to production, load test all of the requests to the server. After running your first load test, you set a baseline. Afterwards, by modifying code or tuning the server, you can improve the numbers until you meet your target. Use this testing approach for all server-side resources that Flex consumes.

Scenario 2

You may run across cases where it seems that the Flex proxy services, network, or some unknown factor is a bottleneck. To troubleshoot this, first rule out the end service. To find the baseline maximum, point your HTTPService request at a static document. To do this, request the JSP or servlet feeding the XML file, save it to a static XML file, and then put the XML file in your webroot. Change the URL of your HTTPService to point to this static document and run your load test again. This provides you not only with a theoretical maximum, but also targets other bottlenecks.

The steps to load test a web service using the <mx:WebService> tag in Flex are almost identical. When viewing your traffic results, you may notice that when the SWF file first loads, it makes a request to the WSDL to load information about the web service. The SWF file makes the request once for each client when the Flex application loads. Requests to methods in the web service follow the WSDL request. If you load test a web service, you may want to load test the WSDL invocation separately from the method calls, because it is not requested nearly as often as the method calls to the service. Some load-test tools let you set up a ratio using different scripts to get the model as close to a real-world scenario as possible.

Scenario 3

Many of the commercial tools also provide powerful scripting languages to customize your scripts and randomize data passed into the request. For example, if you were testing the log-on section of your site, you would not want the same user to log on over and over again in your script. You would instead randomize a set of users in the script so that you mimic different users logging in throughout the load test.

There are some challenges to load testing using RemoteObject with AMF encoding. SOAP uses XML in the request to the server, so it is fairly simple to write a script so that a portion of the XML data is random. AMF is a binary protocol and the request data to the Flash gateway is binary, so not only is it difficult to read what is passed, but it is also difficult to script the requests to include random data. Some commercial load-testing vendors, such as Segue, include AMF as a native protocol to their testing suites to simplify this process.

Near the end of your development cycle, you should run several full-fledged load tests. The commercial tools mentioned previously work best in this situation. Record several common paths that users will take through the application. After recording the different paths, you might need to modify each script, to randomize the data passed to the server. You can then run the scripts against the server while monitoring several different areas on the back end. Monitor the following areas on both your application and database servers: CPU, JVM heap usage, network, and any tools that the application server provides for monitoring.

After completing the tests, analyze the results and try to identify the requests that take the longest to process. The goal is to find bottlenecks and optimize any areas in your application or server. After optimizing your applications, run several long-term MTBF (mean time between failure) tests to ensure that after several hours in production, no preexisting or new issues cause downtime. Although it is impossible to simulate exactly what occurs in a production environment, you can come close. Following the steps and tips outlined previously, and you can be confident that your application will perform well in production with very little downtime.

Page 8 of 9
Previous Page
Next Page