Designing ASP Applications
ASP provides a powerful and extensible framework for creating server-side scripts with any COM compliant scripting or programming language.
Proper Use of ASP
With ASP, you can easily and quickly create Web applications, in a fraction of the time it would take with a more conventional server-side language, such as C or C++.
However, the ease with which you can create ASP-based applications belies the complexity of the server processing and client-server interaction required by that application. It is possible that Web applications that have been created with extensive ASP scripting will not scale well.
To avoid scalability problems, there are two points to keep in mind when developing with ASP:
ASP is the "Glue"
ASP should not be used for business logic
The first point emphasizes that ASP dovetails with HTML, client-side scripting using DHTML, and XML to create a powerful platform for interacting with the user. ASP scripting was designed to be used to bind the user interface to the business logic of the Web application, and ASP was optimized for these sorts of tasks.
The second point should serve as an important reminder: If you find that most of your business logic is embedded into the ASP, your application will probably not scale properly. It is true that ActiveX? scripting languages, hosted by ASP, are capable of accomplishing a great deal of business logic processing. However, if the business logic required for your Web application is more than trivial, then that business logic should be folded into a new COM component, rather than embedded in ASP scripts.
Optimizing ASP Scripts
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. For more information, see the 25+ ASP Tips to Improve Performance and Style TechNet article.
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. 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 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 6.0, the Buffer property is set to TRUE by default. During an upgrade from previous versions of IIS to 6.0, 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 IIS Manager or by adding the <% Response.Buffer = True %> statement to selected pages. You can also change the property for entire applications by using IIS Manager.
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 IIS Manager 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 the following section titled Optimizing ASP Configuration on IIS 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.
Optimizing ASP Configuration on IIS
IIS provides several configuration settings that you can adjust to tune the performance and scalability of your Web applications. Performance tips are provided in the reference page for each property; click a property in following list to see its reference page.