Abstract: This article describes how to optimize ASP applications and VBScript.
Directory
Tip 1: cache frequently used data on a Web server
Tip 2: cache frequently used data in application or session objects
Tip 3: cache data and HTML on the disk of the Web Server
Tip 4: Avoid caching non-agile components in application or session objects
Tip 5: Do not cache database connections in application or session objects.
Tip 6: reasonably use session objects
Tip 7: encapsulate code in a COM Object
Tip 8: Get resources later and release resources earlier
Tip 9: Out-of-process execution processes exchange performance for Reliability
Tip 10: use explicit options
Tip 11: use local variables in subroutines and functions
Tip 12: Copy frequently used data to script variables
Tip 13: avoid re-determining the array dimension
Tip 14: Use response Buffering
Tip 15: batch processing embedded scripts and response. Write statements
Tip 16: If the page takes a long time to complete, use response. isclientconnected before execution.
Tip 17: Use <Object> to mark the example object
Tip 18: Use typelib to bind ADO with other components
Tip 19: Use the browser verification function
Tip 20: Avoid using String concatenation in loop statements
Tip 21: Enable browser and proxy caching
Tip 22: Try to replace response. Redirect with server. Transfer.
Tip 23: Use a backslash in the directory URL
Tip 24: Avoid using server Variables
Tip 25: upgrade to the latest and best
Tip 26: optimize Web Servers
Tip 27: perform a performance test
Tip 28: Read resource links
Introduction
Performance is a feature. You must design the performance in advance, or you will have to rewrite the application later. That is to say, which of the following policies can optimize the performance of Active Server Pages (ASP) applications?
This article describes how to optimize ASP applications and Visual Basic Scripting Edition (VBScript. This article discusses many traps. The recommendations listed in this article have been tested in http://www.microsoft.com and on other sites, with remarkable results. This document assumes that you have a basic understanding of ASP development, including VBScript and/or JScript, ASP application, ASP session, and other ASP inherent objects (request, response, and server.
Generally, ASP performance mainly depends on many factors other than ASP code. We do not list all information in an article. At the end of this article, we list performance-related resources. These links cover ASP and non-Asp topics, including ActiveX Data Objects (ADO), Component Object Model (COM), databases, and Internet Information Server (IIS) configurations. These are some of our favorite links-be sure to check them out.
Tip 1: cache frequently used data on a Web server
A typical ASP page retrieves data from the back-end data storage, and converts the result to an ultra-Text Markup Language (HTML ). Regardless of the database speed, retrieving data from the memory is always much faster than retrieving data from the back-end data storage. Reading data from a local hard disk is usually faster than retrieving data from a database. Therefore, data can be cached on a Web server (stored in memory or disk) to improve performance.
Cache is a traditional practice of exchanging space for time. If the cached content is correct, you can see that the performance will be significantly improved. To make the cache effective, you must save frequently used data and re-calculate the data, which requires a high (moderate) overhead. If old data is cached, the memory will be wasted.
Data that does not change frequently is a good candidate for caching, because you do not have to worry about synchronizing the data with the database over time. Combo list, reference table, DHTML fragment, Extended Markup Language (XML) string, menu item, and site configuration variable (including data source name (DSN), Internet Protocol (IP) address and web path) are good cache candidates. Note that you can cache the "representation" of data instead of the data itself. If the ASP page is rarely changed and the cache overhead is large (for example, the entire product directory), you should consider generating HTML in advance instead of re-displaying each request in response.
Where should data be cached and what are the cache policies? Data is usually cached in the memory or disk of the Web server. The following two tips describe these two methods.
Tip 2: cache frequently used data in application or session objects
ASP application and session objects provide a convenient container for caching data in the memory. You can assign data to application and session objects, which are stored in memory between HTTP calls. Session data is stored separately by each user, while application data is shared among all users.
When will the data be loaded into the application or session? Generally, data is loaded when an application or session is started. To load data during application or session startup, add the appropriate code to application_onstart () or session_onstart. These functions should be in global. Asa. If not, you can add them. You can also load the data at the first time you need it. To this end, add some code (or write a reusable Script Function) to the ASP page to check whether the data exists. If not, load the data. This is a traditional performance technology called "inert computing"-it is not calculated until you know you need a value. Example: program code 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 required data block.
What format should data be stored? Any variant type can be stored, because all script variables are of a variant type. For example, you can store strings, integers, or arrays. Typically, you store the content of the ADO record set as one of these variable types. To obtain data from the ADO record set, you can manually copy the data to the VBScript variable, one field at a time. Using an ADO record set persistence function getrows (), getstring (), or save () (ADO 2.5) can speed up and make it easier. The details are beyond the scope discussed in this article, but the following is a function example, indicating that an array of record set data is returned using getrows (): The program code '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 an array
Rs. Close
Set rs = nothing
End Function
Further improve the preceding example to cache HTML as a list instead of an array. The following is a simple example: the program code '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 do 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 'see release early
Fetchemploymentstatuslist = S' return data as a string
End Function
Under appropriate conditions, the ADO record set itself can be cached in the application or session scope. There are two warnings:
Ado must be marked as a free thread
The disconnected record set must be used.
If the two requirements cannot be met, do not cache the ADO record set. In the following "non-agile components" and "Do not cache connections" techniques, we will discuss the risks of storing COM objects in the application or session scope.
When you store data in the application or session scope, the data is retained until you change it programmatically, the session expires, or the web application restarts. What if data needs to be updated? To manually update application data, you can access ASP pages that only Administrators can access to update data. Alternatively, you can use the function to automatically refresh data on a regular basis. The following example stores the timestamp with cached data and refreshes the data after a period of time. Program code 'error handing not shown...
Const update_interval = 300 'refresh interval, in seconds
'Function to return the employee status list
Function getemploymentstatuslist
Updateemploymentstatus
Getemploymentstatuslist = Application ("employmentstatuslist ")
End Function
'Periodically update the cached data
Sub updateemploymentstatuslist
Dim D, strlastupdate
Strlastupdate = Application ("lastupdate ")
If (strlastupdate = "") or _
(Update_interval <datediff ("S", strlastupdate, now) then
'Note: Two or more CILS might get in here. This is okay and will simply
'Result In A Few unnecessary fetches (there is a workaround for this)
'Fetchemploymentstatuslist function (not shown)
'Fetches data from DB, returns an array
D = fetchemploymentstatuslist ()
'Update the application object. Use application. Lock ()
'To ensure consistent data
Application. Lock
Application ("maid") = events
Application ("lastupdate") = CSTR (now)
Application. Unlock
End if
End sub
For more information, see world's fastest ListBox with application data.
It is not a good practice to cache large arrays in a session or application object. Before accessing any element of the array, the syntax of the script language requires that the entire array be copied temporarily. For example, if an array consisting of 100,000 elements in a string is cached in the Application object, ASP must copy all the 100,000 weather stations to a temporary array before extracting a string. In this case, it would be better to create a custom component using a custom method to store weather stations-or use a dictionary component.
Let's warn you not to drop the baby and bath water together: Arrays can be quickly searched and stored in memory as neighboring key data pairs. Indexing a dictionary peso to index an array is much slower. Select a data structure that provides the best performance based on your actual situation.
Tip 3: cache data and HTML on the disk of the Web Server
Sometimes, too much data may be stored in the memory. "Too many" is just a saying, it depends on how much memory you want to consume, the number of projects to be cached, and the frequency of retrieving these projects. In any case, if there is too much data to be cached in the memory, consider caching the data in text or XML files on the hard disk of the Web server. You can cache data on disks and memory at the same time to create the most appropriate Cache Policy for your site.
Note that when measuring the performance of a single ASP page, retrieving data on a disk may not necessarily be faster than retrieving data from a database. However, the cache will reduce the load on the database and the network. In the case of high load, this can greatly improve the overall throughput. This is very effective when the cache overhead is a large query result set (such as multi-table join or composite Stored Procedure) or a large result set. Test the advantages and disadvantages of several solutions as usual.
ASP and COM provide some tools for creating disk-based Cache solutions. The ADO record set save () and open () functions save and load the record set in the disk. You can use these methods to re-compile the code example in the preceding application data cache technique, and use the SAVE () of the file to replace the code written to the application object.
Some other components can be used for files:
Scripting. FileSystemObject allows you to create, read, and write files.
Microsoft XML Parser (MSXML) provided with Internet Explorer supports saving and loading XML documents.
Lookuptable objects (for example, used on MSN) are the best option to load a simple list from a disk.
Finally, you should consider caching the data representation on the disk, rather than the data itself. Pre-converted HTML files can be stored on disks using. htm or. asp files. Hyperlinks can direct to these files. You can use commercial tools such as xbuilder or the Microsoft SQL Server Internet publishing function to automate the HTML process. Alternatively, you can place HTML code snippets in The. asp file. You can also use FileSystemObject to read HTML files from the disk, or use XML for Early conversion.