ASP Scripting Optimization

[This is preliminary documentation and subject to change]

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.1. 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.
Setting buffer property of the Response Object In IIS 4.0, the Buffer property of the ASP Response object was set to FALSE by default. With a new installation of IIS 5.1, the Buffer property is set to TRUE by default. During an upgrade from previous versions of IIS to IIS 5.1, the Buffer property is not changed from its previous setting. Setting the Buffer property to TRUE can significantly improve the performance of large ASP applications in which users primarily connect to the application by means of a modem. You can enable buffering for your applications from the IIS snap-in or by adding the <% Response.Buffer = True %> statement to selected pages. You can also change the property for entire applications by using the IIS snap-in.
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 does not instantiate the object. In contrast, Server.CreateObject forces IIS to immediately create an instance of the object, whether the script uses the object or not.
Use local variables, avoid public variables. The ASP scripting engine can access local variables quicker than public variables because the entire namespace does not need 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 many concurrent users are using your application, the server's resources may become depleted, and performance may be affected. You should disable session state for the parts of your application that don't need session state 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, 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 is lost because IIS is 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 many concurrent users are using your application, the server's resources may become depleted, and performance may 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.