ASP Scripting Optimization

Code optimization should be performed carefully. In ASP scripting, as in any other programming language, it is important to determine which areas of the application are consuming the most time and resources. This information can then be used to efficiently target the critical area for optimization.

Here are several tips that might help minimize performance problems in your ASP scripts:

• Cache Application-scoped objects and data, either by creating the object in Global.asa, or creating it on-demand in an individual ASP script, and placing it in Application scope.
• Combine output of Response.Write calls by relying on ASP buffering, which is on by default with IIS 5.0. In order to improve the perceived performance of applications that use buffered output while performing time-consuming operations, however, your application should periodically use Reponse.Flush to maintain contact with the user.

  If ASP buffering has been disabled for your Web application, performance may be improved if you minimize the number of separate calls to Response.Write by combining separate output strings into one larger string. However, if you must perform extensive string manipulations to accomplish this, the gain in performance is probably offset by the time spent processing the strings.

• Use <OBJECT> tags instead of Server.CreateObject, when instantiating objects at Application or Session scope. The reason is that IIS delays actually instantiating the object specified by <OBJECT> tags until the object is actually put to use. If you use <OBJECT> tags, and your script never uses the object, then your application will not instantiate the object. In contrast, Server.CreateObject forces IIS to immediately create an instance of the object, whether the object is used by the script or not.
• Use local variables, avoid public variables. Local variables can be accessed quicker by the ASP scripting engine than public variables, because the entire namespace doesn't have to be searched to access the value of a local variable.
• Use client-side validation of user input, where possible, to minimize the HTTP round trips required. If the browser is full-featured, harness the power of the browser, and free up server-side resources for more critical tasks. Of course, some integrity checking still should be performed on the server, depending on the application, as an extra precaution against data corruption.
• Copy individual values from collections into local variables, if you are going to reference the value more than once. This saves ASP from having to perform lookup processing in the collection for each and every reference.
• Turn off session state for the entire application, if possible. If your application does not require the use of IIS sessions, you should use the Internet Information Services snap-in to disable session state for the entire application. Sessions in IIS remain in memory, and the memory allocated to the sessions will not be freed until the session has been terminated or timed-out. If your application is being used by many concurrent users, the server's resources could become depleted, and performance could be affected. If some parts of your application don't need session state, you should disable session state for those pages by using the @ENABLESESSIONSTATE directive.

  Turning off session state whenever possible is especially helpful if the page contains a <FRAMESET> element. Some browsers, including Internet Explorer, will use separate threads to process the separate frames of the frameset. If session state is turned on for the frameset page, the client-side performance benefit of these parallel threads will be lost, because IIS will be forced to serialize the threads processing the separate requests.

• If you do rely on session state, avoid placing large amounts of data into the Session object, and into session state. Sessions in IIS are persistent, and the memory allocated to the sessions will not be freed until the session has been terminated or timed-out. If your application is being used by many concurrent users, the server's resources could become depleted, and performance could be affected.
• Do not provide empty Session_OnStart or Session_OnEnd.
• Pay close attention to the effects of IIS and ASP configuration changes. See IIS Configuration Optimization for more details.
• If your ASP page is running as part of an application, designate the application as out-of-process for application debugging only. Process isolation, which was introduced in IIS 4.0, is a useful capability. The cross-process marshalling required to support process isolation, however, can introduce a certain amount of overhead to ASP processing. This difference in overhead is most significant for simple ASP pages, and is less of a concern for more complex pages. To maximize scalability and performance, however, consider running the application out-of-process only until it is sufficiently debugged and stable to be run in-process with IIS.
• Avoid ReDimming arrays, if possible. It is more efficient to simply allocate the full size of the array when the array is first initialized.