Skills | Performance 28 tips for improving ASP performance and appearance
Len Cardinal, Senior Advisor, Microsoft Consulting Services George v. Reilly
Microsoft IIS Performance Lead
From Nancy Cluts's article. Developer Technical Engineer
Microsoft Corporation
April 2000
Summary: This article describes the techniques for optimizing ASP applications and VBScript.
Directory
Tip 1: Cache frequently used data on a WEB server
Tip 2: Cache frequently used data in a application or Session object
Tip 3: Cache data and HTML on a WEB server's disk
Tip 4: Avoid caching non agile components in a application or Session object
Tip 5: Do not cache database connections in application or session objects
Tip 6: Use session objects appropriately
Tip 7: Encapsulate code in a COM object
Introduction
Performance is a feature. You must design the performance beforehand, or you will have to rewrite the application later. That is, what are some good strategies for enabling Active Server Pages (ASP) application performance to be optimal?
This article describes optimizing ASP applications and Visual Basic? Scripting Edition (VBScript) techniques. This article discusses a number of pitfalls. The recommendations listed in this article have been tested in http://www.microsoft.com and other sites with significant results. This article assumes that you have a basic understanding of ASP development, including VBScript and/or JScript, ASP application, ASP sessions, and other ASP-intrinsic objects (Request, Response, and Server).
Typically, ASP performance is largely dependent on a number of factors outside the ASP code itself. We don't list all the information in an article, and at the end of this article we list the resources that are related to performance. These links cover ASP and non-ASP topics, including ActiveX? Data Objects (ADO), Component Object Model (COM), database, and Internet information Server (IIS) configuration. These are some of our favorite links-be sure to go and see.
Tip 1: Cache frequently used data on a WEB server
A typical ASP page retrieves data from the back-end data store and then converts the results to Hypertext Markup Language (HTML). Retrieving data from memory is much faster than retrieving data from the back-end data store, regardless of the speed of the database. Reading data from a local hard disk is usually faster than retrieving data from the database. As a result, you can typically cache data on a WEB server (stored in memory or on a disk) to improve performance.
Caching is a traditional way of exchanging time in space. If you're caching the right content, you can see a significant improvement in performance. For caching to be valid, data that is frequently reused must be saved, and a large (modest) overhead is needed to recalculate the data. If all of the cached data is stale, it can cause memory waste.
Data that is infrequently changed is a good candidate for caching because you do not have to worry about synchronizing the data with the database over time. combo box lists, reference tables, DHTML fragments, Extended Markup Language (XML) strings, menu items, and site configuration variables, including data source names (DSNs), Internet Protocol (IP) addresses, and Web paths, are good candidates for caching. Note that you can cache the "representation" of the data without caching the data itself. If ASP pages are rarely changed and the cache is expensive (for example, the entire product catalog), you should consider producing HTML in advance, rather than showing it again in response to each request.
Where should the data be cached, and what caching policies are there? Typically, data is cached on the WEB server's memory or disk. The next two tips tell the two ways.
Tip 2: Cache frequently used data in a application or Session object
ASP Application and Session objects provide a convenient container for caching data in memory. You can assign data to application and session objects, which remain in memory between HTTP calls. Session data is stored separately for each user, while application data is shared among all users.
When will the data be loaded into the application or session? Typically, data is loaded when the application or session is started. To load data during the application or session startup process, add the appropriate code to either Application_OnStart () or Session_OnStart (). These functions should be in Global.asa, and if they are not, you can add them. You can also mount the data the first time it is needed. To do this, add some code (or write a reusable script function) to the ASP page to check whether the data exists, and if not, load the data. This is a traditional performance technique, called lazy computing, that does not calculate a value until you know it is needed. For example:
<%
Function getemploymentstatuslist
Dim D
d = Application (? Employmentstatuslist?)
If d =?? Then
' Fetchemploymentstatuslist function (not shown)
' Fetches data from DB, returns an Array
D = fetchemploymentstatuslist ()
Application (? Employmentstatuslist?) = d
End If
Getemploymentstatuslist = d
End Function
%>
You can write similar functions for each block of data that you need.
In what format should the data be stored? You can store any variant type, because all script variables are variant types. For example, you can store strings, integers, or arrays. Typically, you will store the contents of an ADO recordset as one of these variable types. To get data from an ADO recordset, you can manually copy the data to a VBScript variable, one field at a time. Using an ADO recordset Persistence function GetRows (), GetString (), or Save () (ADO 2.5) can be faster and easier. The details are beyond the scope of this article, but here is an example of a function that uses GetRows () to return an array of recordset data:
' Get Recordset, return as an Array
Function fetchemploymentstatuslist
Dim RS
Set rs = CreateObject (? ADODB. Recordset?)
Rs. Open? Select Statusname, Statusid from Employeestatus?, _
? dsn=employees;uid=sa;pwd=;?
Fetchemploymentstatuslist = Rs. GetRows ()? Return data as a Array
Rs. Close
Set rs = Nothing
End Function
For a further improvement on the above examples, you can cache HTML as a list, not an array. The following is a simple example:
' Get Recordset, return as HTML Option list
Function fetchemploymentstatuslist
Dim RS, Fldname, S
Set rs = CreateObject (? ADODB. Recordset?)
Rs. Open? Select Statusname, Statusid from Employeestatus?, _
? dsn=employees;uid=sa;pwd=;?
s =? <select name=?? Employmentstatus?? "?" & VbCrLf
Set fldname = Rs. Fields (? Statusname?) ' ADO Field Binding
Do Until Rs. Eof
' Next line violates Don ' t does String concats,
' But it ' s OK because we are building a cache
s = S &? <option>? & Fldname & </option>? & VbCrLf
Rs. MoveNext
Loop
s = S & </select>? & VbCrLf
Rs. Close
Set rs = Nothing ' Early
Fetchemploymentstatuslist = S ' return data as a String
End Function
Under the appropriate conditions, you can cache the ADO recordset itself in the application or session scope. There are two warnings:
ADO must be marked as free thread
You must use a disconnected recordset.
If these two requirements are not guaranteed, do not cache the ADO recordset. In the following "non-agile components" and "Do not cache connections" techniques, we will discuss the dangers of storing COM objects in the application or session scope.
When you store data in the application or session scope, the data remains there until you programmatically change it, session expiration, or the WEB application restarts. What if the data needs to be updated? To manually force updates to application data, you can access ASP pages that only administrators can access to update the data. Alternatively, you can automatically refresh the data periodically through functions. The following example stores a timestamp with cached data and refreshes the data after a period of time.
<%
' ERROR handing not shown ...
Const update_interval = ' Refresh inter '
