When testing applications for performance, it is important to configure the client properly.
When you test your applications for performance, use the standard version of Adobe® Flash® Player or AIR rather than the debugger version of Flash Player or ADL, if possible. The debugger version of Player provides support for the trace() method and the Logging API. Using logging or the trace() method can significantly slow player performance, because the player must write log entries to disk while running the application.
If you do use the debugger version of Flash Player, you can disable logging and the trace() method by setting the TraceOutputFileEnable property to 0 in your mm.cfg file. You can keep trace() logging working, but disable the Logging API that you might be using in your application, by setting the logging level of the TraceTarget logging target to NONE, as the following example shows:
myLogger.log(LogEventLevel.NONE, s);
For performance testing, consider writing run-time test results to text components in the application rather than calling the trace() method so that you can use the standard version of Flash Player and not the debugger version of Flash Player.
For more information about configuring trace() method output and logging, see Logging.
If you are running performance tests on a Windows laptop computer, disable Intel SpeedStep functionality. SpeedStep toggles the speed of the CPU to maximize battery life. SpeedStep can toggle the CPU at unpredictable times, which makes the results of a performance test less accurate than they would otherwise be.
The Power Options Properties dialog box displays.
When you test your application, be aware of the scriptTimeLimit property. If an application takes too long to initialize, Flash Player warns users that a script is causing Flash Player to run slowly and prompts the user to abort the application. If this is the situation, you can set the scriptTimeLimit property of the <mx:Application> tag to a longer time so that the Flex application has enough time to initialize.
However, the default value of the scriptTimeLimit property is 60 seconds, which is also the maximum, so you can only increase the value if you have previously set it to a lower value. You rarely need to change this value.
The following example sets the scriptTimeLimit property to 30:
<?xml version="1.0"?>
<!-- optimize/ChangeScriptTimeLimit.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" scriptTimeLimit="30">
<!-- Empty application -->
</mx:Application>
When you test performance, ensure that you are not serving files from the local cache to Flash Player. Otherwise, this can give false results about download times. Also, during development and testing, you might want to change aspects of the application such as embedded images, but the browser continues to use the old images from your cache.
If the date and time in the If-Modified-Since request header matches the date and time in the Last-Modified response header, the browser loads the SWF file from its cache. Then the server returns the 304 Not Modified message. If the Last-Modified header is more recent, the server returns the SWF file.
You can use the following techniques to disable client-side caching:
// Set Cache-Control to no-cache.
response.setHeader("Cache-Control", "no-cache");
// Prevent proxy caching.
response.setHeader("Pragma", "no-cache");
// Set expiration date to a date in the past.
response.setDateHeader("Expires", 946080000000L); //Approx Jan 1, 2000
// Force always modified.
response.header("Last-Modified", new Date());