ASP Skill Collection (Official Authority edition)-1

Skills Brief Introduction
Performance is an attribute. You need to design your performance in advance, or rewrite your application later. In other words, what is a good strategy for maximizing the performance of Active Server Pages (ASP) applications?
This article provides a number of tips for optimizing ASP applications and the Visual Basic (R) Script Editor (VBScript). Many pitfalls and flaws were discussed. The recommendations listed in this article have been tested on http://www.microsoft.com and other sites and are working properly. This article assumes that you have a basic understanding of ASP development, including for VBScript and/or JScript, ASP application, ASP sessions, and other ASP internal objects (requests, responses, and servers).
ASP's performance, usually depends not only on the ASP code itself. We do not want to include all the wisdom in an article, but only at the end of the list of resources related to performance. These links include ASP and non-ASP topics, including ActiveX (R) Data Objects (ADO), part object Model (COM), databases, and Internet Information Server (IIS) configurations. These are our favorite links-be aware of them.
　　
　　 Tip 1: Caching common data on a WEB server
A typical ASP page retrieves data from the back-end database and then converts the result to Hypertext Markup Language (HTML). Retrieving data from memory is much faster than retrieving data from a back-end database, regardless of the speed of the database. Reading data from a local hard disk is often much faster than retrieving data from a database. As a result, you can often improve performance by caching data on a WEB server (in memory or disk).
Caching is a typical tradeoff between space and time. If you cache the data appropriately, you will see a dramatic improvement in performance. To make the cache work, it must maintain data that is frequently reused, and the cost of recalculation of the data is expensive or more expensive. If the cache is full of garbage data, it is a waste of memory.
Data that is infrequently changed is also a cached candidate because you do not have to worry about synchronizing data with the database. combo boxes, reference tables, DHTML fragments, Extensible Markup Language (XML) strings, menu items, and site configuration variables, including data source names (DSNs), Internet Protocol (IP) addresses, and Web paths) are cached candidate data. Note that you can cache the representation of the data rather than the data itself. If ASP pages do not change frequently and the cost of caching is very high (for example, the entire product catalog), consider generating HTML beforehand, rather than redrawing each request.
Where should the data be cached, and what caching policies are there? Data is often cached on Web server memory or on a Web server disk. The following two tips discuss these options.
　　
　　 Tip 2: Cache commonly used data in application or session objects
ASP Application and Session objects provide a convenient container for caching data in memory. You can either give the data to the Application object or assign the data to the session object, which will remain in memory in the HTTP call. Session data is stored by user, and application data is shared among all users.
When will data be loaded into application or session? Typically, the data is loaded when the application or session is started. To load data at application or session startup, add the appropriate code in the following two functions: Application_OnStart () or Session_OnStart (). These two functions should be in Global.asa, and if not, you can add these functions. You can also load data the first time you need it. To do this, add some code (or write reusable script functions) to the ASP page that checks for the existence of the data and loads the data when it does not exist. This is an example of a classical energy technique called lazy Computing-no calculation before you really need it. Take a look at the example:
<%
Function getemploymentstatuslist
Dim D
D = Application ("Employmentstatuslist")
If d = "" Then
' Fetchemploymentstatuslist function (not shown)
' Fetch data from DB, return array
D = fetchemploymentstatuslist ()
Application ("employmentstatuslist") = d
End If
Getemploymentstatuslist = d
End Function
%>
You can write similar functions for each piece of data that you want.
What format should the data be stored in? Any variable type can be stored, because all script variables are different. 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 derived from an ADO recordset, you can manually copy the data into a VBScript variable, one field at a time. Using an ADO recordset to preserve Functions GetRows (), GetString (), or Save () (ADO 2.5) is faster and easier. The full and detailed content is beyond the scope of this article. The following demo function uses GetRows () to return an array of recordset data:
' Fetch Recordset, return with 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 () ' Returns data as an array
Rs. Close
Set rs = Nothing
End Function
Further improvements to the above example should be to cache the HTML of the list, rather than caching the array. The following is a simple example:
' Take the recordset and return it in the HTML options 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 bindings
Do Until Rs. Eof
' The following line violates the need for string concatenation,
' But that's OK because we're building a cache
s = S & "<option>" & Fldname & "</option>" & VbCrLf
Rs. MoveNext
Loop
s = S & "</select>" & VbCrLf
Rs. Close
Set rs = Nothing ' See early release
Fetchemploymentstatuslist = S ' returns data as a string
End Function
In normal circumstances, you can cache the ADO recordset itself in the application or session scope. There are two warnings:
ADO must be a free thread for marking
You must use a disconnected recordset.
If you are not guaranteed to meet both requirements, do not cache the ADO recordset. In the following inflexible components and do not cache connection tips, we will discuss the dangers of storing COM objects in the application or session scope.
If you store data in a application or session scope, the data remains there until you change it in your program, session expiration, or WEB application restarts. What does the data need to be updated to handle? To force the application data to be manually updated, you can invoke data that is only accessible to the administrator to update the ASP page. In addition, the data can be automatically refreshed periodically through functions. The following example stores a timestamp with cached data and refreshes the data after a specified interval.
<%
' Error handling not shown ...
Const update_interval = 300 ' Refresh time interval, in seconds
　　
' function returns the list of employment status
Function getemploymentstatuslist
Updateemploymentstatus
Getemploymentstatuslist = Application ("Employmentstatuslist")
End Function
　　
' Periodically update cached data
Sub updateemploymentstatuslist
Dim D, Strlastupdate
Strlastupdate = Application ("Lastupdate")
If (strlastupdate = "") Or _
(Update_interval DateDiff ("s", Strlastupdate, now) Then
　　
' Note: There may be two or more calls here. It's okay, it's just
' Generates a few unnecessary commands (there is a workspace for this)
　　
' Fetchemploymentstatuslist function (not shown)
' Fetch data from DB, return an array
D = fetchemploymentstatuslist ()
　　
' Update the Application object. With Application.Lock ()
' To ensure consistent data
Application.Lock
Application ("employmentstatuslist") = d
Application ("lastupdate") = CStr (now)
Application.UnLock
End If
End Sub
%>
For other examples, see the fastest list box with application data.
Note that caching large arrays in a session or Application object is not the best policy. Before accessing an array element, the scripting language syntax requires that a temporary copy of the entire array be established. For example, if you cache a string array that maps a U.S. ZIP code to a local weather station in the Application object, which has 100,000 elements, the ASP must copy all 100,000 weather stations to a temporary array before it finds a string. In this case, it might be better to create a custom component with a custom method to store the weather station-or use a dictionary component.
Please don't pour the child out with the bath water. A new note to this view is that arrays provide fast lookup and storage of adjacent key-data pairs in memory. Index dictionary peso array is slow. You should choose the data structure that provides the best performance based on the circumstances.