24 ASP tips for improving performance and styles page 1/2

Xiangxian content:
Introduction

Tip 1: cache common data on a Web server

Tip 2: cache common data in application or session objects

Tip 3: cache data and HTML on the Web server disk

Tip 4: Avoid caching non-flexible components in the application or Session Object

Tip 5: Do not cache database connections in application or session objects

Tip 6: Use session objects

Tip 7: encapsulate in a COM ObjectCode

Tip 8: Get resources later and release resources earlier

Tip 9: Off-process execution sacrifices Reliability

Tip 10: use options explicitly

Tip 11: use local variables in subroutines and functions

Tip 12: Copy common data to script variables

Tip 13: Avoid redefining Arrays

Tip 14: Use response Buffering

Tip 15: batch processing embedded scripts and response. Write statements

Tip 16: Use response. isclientconnected before starting a long task

Tip 17: Use <Object> to mark the object to be instantiated

Tip 18: bind the ADO object to typelib of other components

Tip 19: Use the browser's verification capability

Tip 20: Avoid String concatenation in a loop

Tip 21: Enable browser and proxy caching

Tip 22: Try to replace response. Redirect with server. Transfer

Tip 23: Add a slash to the end of the Directory URL

Tip 24: Avoid using server Variables

--------------------------------------------------------------------------------

Introduction

Performance is a feature. You need to design performance in advance or re-compile the application in the futureProgram. In other words, what is a good policy to maximize the performance of Active Server Pages (ASP) applications?

This article provides many tips for optimizing ASP applications and Visual Basic (r) Script Editor (VBScript. Many traps and defects are discussed. The recommendations listed in this article are all tested on http://www.microsoft.com and other sites and work properly. This document assumes that you have a basic understanding of ASP development, including VBScript and/or JScript, ASP application, ASP session, and other ASP internal objects (requests, responses, and servers ).

The performance of ASP is usually not limited to ASP code. We do not wantArticleContains all the rationaleFamous saying, Only the performance-related resources are listed at the end. These links include ASP and non-Asp topics, including "ActiveX (r) Data Object (ADO)", "part Object Model (COM)", databases, and "Internet Information Server (IIS) "configuration. These are our favorite links-please pay attention to them.

Tip 1: cache common data on a Web server

A typical ASP page retrieves data from a back-end database and converts the result to HTML ). Regardless of the database speed, retrieving data from the memory is much faster than retrieving data from the back-end database. Reading data from a local hard disk is usually much faster than retrieving data from a database. Therefore, you can cache data on a Web server (in memory or disk) to improve performance.

Cache is a typical compromise between space and time. If you cache data properly, you will see an amazing improvement in performance. To make the cache effective, it must maintain the data that is frequently reused, and the cost of re-computing the data is expensive or relatively expensive. If the cache is full of junk data, it is a waste of storage.

Infrequently changed data is also a candidate cache data because you do not have to worry about data synchronization with the database. Combo box, reference table, DHTML fragment, Extensible Markup Language (XML) string, menu item, and site configuration variable (including data source name (DSN), Internet Protocol (IP) address and web path) are cache candidate data. Note: You can cache the representation of data rather than the data itself. If the ASP page is not changed frequently and the cache cost is very high (for example, the entire product directory), consider generating HTML in advance instead of re-drawing each request.

Where should the data be cached? What are the cache policies? Data is often cached in the web server memory or on the Web server disk. The following two tips discuss these options.

Tip 2: cache common data in application or session objects

ASP application and session objects provide a convenient container for caching data in the memory. You can grant data to the application object or session object, which will be stored in the memory during HTTP calls. Session data is stored by users, and application data is shared among all users.

When Will data be loaded into the application or session? Generally, data is loaded when an application or session is started. To load data at application or session startup, add the corresponding code to the following two functions:
Application_onstart ()
Or
Session_onstart ()
. These two functions should be in global. Asa; if not, you can add these functions. You can also load data when you need data for the first time. To perform the preceding operations, add some code (or write reusable script functions) on the ASP page to check whether the data exists and load the data when the data does not exist. This is an example of a classic performance technology called slow computing-without computing until you actually need it. See the example below:

<%
Function getemploymentstatuslist
Dim d
D = Application ("employmentstatuslist ")
If D = "" then
'Fetchemploymentstatuslist function (not displayed)
'Retrieve data from the DB and return an array
D = fetchemploymentstatuslist ()
Application ("employmentstatuslist") = d
End if
Getemploymentstatuslist = d
End Function
%>

You can write similar functions for each piece of data.

What format should data be stored? Any variable type can be stored, because all script variables are different. For example, strings, integers, or arrays can be stored. Typically, you store the content of the ADO record set as one of these variable types. To obtain the data derived 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 retention function getrows (), getstring (), or save () (ADO 2.5) makes it faster and easier. The complete and detailed content is beyond the scope of this article. The following demo function uses
Getrows ()
To return the array of record set data:

'Retrieve record set and return it 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 () 'returns data in an array.
Rs. Close
Set rs = nothing
End Function

The further improvement of the above example should be to cache the HTML of the list, rather than the cache array. The following is a simple example:

'Retrieve record set, returned in the "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
'The following Line violates the need to establish a string connection,
'But this is fine, because we are creating a cache
S = S & "<option>" & fldname & "</option>" & vbcrlf
Rs. movenext
Loop
S = S & "</SELECT>" & vbcrlf
Rs. Close
Set rs = nothing 'see release as soon as possible
Fetchemploymentstatuslist = S' returns data with a string
End Function

Normally, you can cache the ADO record set in the application or session scope. There are two warnings:

The free thread that ADO must mark
The disconnected record set must be used.
If these two requirements cannot be met, do not cache the ADO record set. In the following non-flexible components and do not cache connections, we will discuss the danger of storing COM objects in the application or session scope.

If data is stored in the application or session scope, the data is retained until it is changed in the program, the session expires, or the web application restarts. What should I do if data needs to be updated? To manually update application data, you can call the data update ASP page that is only accessible to administrators. In addition, you can use functions to automatically refresh data periodically. The following example stores the timestamp with cached data and refreshes the data after the specified interval.

<%
'The error handling is not displayed...
Const update_interval = 300 'refresh interval, in seconds

'Function returns the list of employment statuses
Function getemploymentstatuslist
Updateemploymentstatus
Getemploymentstatuslist = Application ("employmentstatuslist ")
End Function

'Regularly 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. This is okay,
'The command is unnecessary (there is a workspace)

'Fetchemploymentstatuslist function (not displayed)
'Retrieve data from the DB and return an array
D = fetchemploymentstatuslist ()

'Update the application object. Use 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 (in English ).

Note that caching large arrays in a session or application object is not the best practice. Before accessing the array elements, the syntax of the script language requires creating a temporary copy of the entire array. For example, if the application object caches a string array that maps the U.S. Postal code to the local weather station, the string array contains 100,000 elements. Before ASP finds a string, all 100,000 weather stations must be copied to the temporary array. In this case, it may be better to create custom components with custom methods to store weather stations-or use a dictionary component.

Please do not drop the child together when pouring the bath water. A new comment on this idea is that the array provides fast search and storage for adjacent key-data pairs in the memory. The index dictionary is slower than the index array. You should select a data structure that provides the best performance according to the specific situation.

Tip 3: cache data and HTML on the Web server disk

Sometimes, too much data cannot be cached in the memory. "Too much" is a qualitative judgment; it depends on the amount of memory to be consumed, as well as the number of cache items and the retrieval frequency of these items. In short, if there is too much data to be cached in the memory, consider caching data in the form of text or XML files on the hard disk of the Web server. You can combine cached data on the disk and cached data in the memory to create an optimal Cache Policy for the site.

Note: When measuring the performance of a single ASP page, retrieving data on the disk is not necessarily faster than retrieving data from the database. However, caching reduces the load on databases and networks. Under high load, this will significantly increase the overall traffic. When the query cost is high, the query results are cached, And the cache is very effective, such as multi-Table union, complex stored procedures, or large result sets. Test the competitive solution by convention.

ASP and COM provide several tools for creating disk cache solutions. The SAVE () and open () Functions of the ADO record set save and load the record set on the disk. You can use these methods to override the sample code in the preceding application data caching technique and replace the code that writes data to the application object with the SAVE () file.

There are other file processing components:

Scripting. FileSystemObject enables you to create, read, and write files.
MSXML is a Microsoft (r) XML Parser provided with Internet Explorer. It supports saving and loading XML documents.
Lookuptable objects (examples used on MSN) are good choices for loading a simple list from a disk.
Finally, consider caching the data representation on the disk, rather than the data itself. Pre-fabricated HTML files can be stored on disks as. htm or. asp files. Hyperlinks can direct to these files. You can use commercial tools such as xbuilder or Microsoft (r) SQL Server's Internet publishing function to automate the HTML generation process. In addition, you can include the HTML segment # To The. asp file. You can also use FileSystemObject to read HTML files from the disk or use XML for early adjustments ).

Tip 4: Avoid caching non-flexible components in the application or Session Object

Although it is a good idea to cache data in the application or session object, the cached COM object may have serious defects. Embedding a common COM object into an application or session object is usually attractive. Unfortunately, many COM objects, including COM objects written in Visual Basic 6.0 or earlier versions, will cause serious bottlenecks when stored in application or session objects.

Especially for any non-flexible components, caching in session or application objects will lead to performance bottlenecks. Flexible components are marked
Threadingmodel = both
(It aggregates the free thread collector (FTM) or
Threadingmodel = neutral
Components (Windows (r) 2000 and COM + added "neutral" model .) The following components are not flexible:

Free-threaded components (unless they aggregate FTM ).
Unit thread component.
Single-threaded components.
The configured components (Microsoft Transaction Server (MTS)/COM + Library and server package/application) are non-flexible components unless they are "neutral" threads. Unit thread components and other non-flexible components are most suitable for working in the page scope (that is, they are created and destroyed on a single ASP page ).

In IIS 4.0, mark
Threadingmodel = both
Is considered flexible. In IIS 5.0, this is not enough. Components must not only be marked as both, but also FTM. The flexibility article explains how to enable the C ++ component compiled with the "activity template library" to aggregate FTM. Note that if the component caches interface pointers, these pointers must be flexible or stored in "com global interface table (GIT. If you cannot re-compile the both thread component to aggregate FTM, you can mark the component
Threadingmodel = neutral
. In addition, if you do not want IIS to perform a flexibility check (in this way, you want non-flexible components to be stored in the application or session scope), you can set
Asptrackthreadingmodel
Is
True
. Do not change
Asptrackthreadingmodel
.

If you try to store
Server. Createobject
If you create a non-flexible component, IIS 5.0 will produce an error. You can use
<Object runat = server scope = application...>
Solve this problem, but do not advocate this, because it will lead to collection and serialization, as described below.

What will happen if the cache is not a flexible component? The non-flexible component cached in the session object will lock the session to an ASP worker thread. ASP maintains a worker thread pool that provides services to requests. Generally, new requests are processed by the first available worker thread. If the session is locked to a thread, the request will have to wait until the Thread associated with the session becomes available. For example, you enter a supermarket, select some foods, and pay for the food at the cashier's desk on the 15th. Since then, every time you purchase food in this supermarket, you have to pay for the food at the cashier no. 3rd, even if there are few or no other payers.

Storing non-flexible components in the applicaton scope may even have a more serious impact on performance. ASP will have to create a dedicated thread to run non-flexible components within the scope of applicaton. This results in two consequences: All calls have to be aggregated into this thread, and all calls are serialized. Aggregation means that parameters have to be stored in the shared area of the memory; expensive context switching is performed on the dedicated thread; component methods are executed; and results are collected to the shared area; and after another expensive context switch, the control is returned to the original thread. Serialization means that all methods must run one by one (only one method can be run at a time ). Two different ASP worker threads cannot execute methods on shared components at the same time. This will eliminate parallel mechanisms, especially on multi-processor computers. Even worse, all non-flexible components within the application scope will share a thread ("host sta"), so the impact of serialization is more serious.

Are you confused? Below we propose several general rules. If you are writing objects in Visual Basic (6.0) or earlier versions, do not cache them in application or session objects. If you do not know the thread model of the object, do not cache it. Do not cache non-flexible objects, but create and release them on each page. The object will run directly on the ASP worker thread, so that it will not be pooled OR serialized. If COM objects are running in the IIS box and they are not initialized or canceled for a long time, the performance will be sufficient. Note: Do not use this method to use single-threaded objects. Be careful: VB can create single-threaded objects! If you must use a single-threaded object (such as a Microsoft Excel spreadsheet) in this way, do not expect high throughput.

When ADO is marked as a free thread, it is safe to cache the ADO record set. To mark ADO as a free thread, use the makfre15.bat file, which is usually located in the following directory: \ Program Files \ common \ System \ ADO.

Warning if you are using Microsoft Access as a database, do not mark ADO as a free thread. Generally, the ADO record set must be disconnected. If you cannot control the ADO configuration of the site (for example, you are an independent software vendor [isV] and sell the web application to the customer, then they will manage their own configurations), so it may be better to not cache the record set.

Dictionary components are flexible objects. Lookuptable loads its data from the data file, and it is useful for the data and configuration information of the combo box. The pagecache object from duwamish books provides directory semantics, which is the same as caprock dictionary. These objects or their derived objects can form the basis of an effective Cache Policy. Note that the scripting. dictionary object is not flexible, so it should not be stored in the application or session scope.

Tip 5: Do not cache database connections in application or session objects

Caching ADO connections is usually a bad strategy. If a connection object is stored in the application and used on all pages, all pages will compete for the connection. If the connection object is stored in an ASP Session object, a database connection is created for each user. This damages the benefits of the connection pool and puts unnecessary pressure on web servers and databases.

The method to replace the cache database connection is to create and cancel an ADO object on each ASP page that uses ADO. This is an effective method because IIS has a built-in database connection pool. More accurately, IIS automatically enables oledb and ODBC connection pools. This ensures that the connection on each page is valid.

Since the connected record set stores reference to the database connection, the connected record set should not be cached in the application or session object. However, you can safely cache the disconnected record set because it does not contain references to its data connection. To disconnect a record set, perform the following two steps:

Set rs = server. Createobject ("ADODB. recordset ")
Rs. cursorlocation = aduseclient 'step 2

'Insert a record set with data
Rs. Open strquery, strprov

'Disconnect the record set from the same data provider and data source.
Rs. activeconnection = nothing 'step 2

For more information about the connection pool, see ADO and SQL Server references.

Tip 6: Use session objects

After affirming the advantages of caching in applications and sessions, we recommend that you avoid using session objects. Sessions has several disadvantages when used for busy sites. Busy usually refers to the number of pages requested by the site per second or thousands of users at the same time. This technique is more important for sites that require horizontal scaling, that is, those that use multiple servers to adapt to the load or perform fault tolerance. The convenience of small sites, such as Intranet sites and sessions, is also worth comparing with the overhead.

To rebuild, ASP automatically creates a session for each user accessing the web server. Each session has a memory overhead of about 10 KB (which is the highest among any data stored in the session) and slows down all requests. The session remains active until the configurable timeout (usually 20 minutes) is reached.

The biggest problem with sessions is not performance but scalability. A session cannot span the Web server. Once a session is created on a server, its data remains there. This means that if you use sessions in the Web field, you have to design a policy for each user's requests so that these requests are always directed to the server where the user's session is located. This is called "sticking" a user to a Web server. The term "Sticky session" comes from this. Because the session is not kept on the disk, when the web server crashes, users who are "stuck" will lose their sessions status.

Policies for implementing sticky sessions include hardware and software solutions. For example, the network load balancing solution in Windows 2000 Advanced Server and the Cisco Local pointing tool solution can implement sticky sessions at the cost of some scalability. These solutions are not perfect. We do not advocate that you overwrite your software solution (we used ISAPI filters and URL straightening to check the solution ).

Application objects cannot span servers. If you need to share and update application data in the Web field, you need to use backend databases. However, read-only application data is still useful in the Web field.

If you only want to increase the normal running time (for troubleshooting failover and server maintenance), most sites that execute important tasks will need to deploy at least two web servers. Therefore, when designing applications that execute important tasks, you need to implement "Sticky sessions ", or simply avoid sessions and any other State management technology that stores user statuses on a single web server.

If sessions is not currently used, make sure to disable it. You can use "Internet Service Manager" (see the ISM documentation) to perform this operation for the application. If you decide to use sessions, you can use several methods to minimize the impact on performance.

You can move the content that does not require sessions (such as the "help" screen and visitor area) to a separate ASP application with sessions disabled. You can prompt ASP one by one: you do not need a session object on a given page; use the following command at the top of the ASP page:

<% @ Enablesessionstate = false %>

A good reason for using this command is that session brings interesting problems to the framework set. ASP ensures that only one session request is executed at any time. This ensures that when the browser requests multiple pages for a user, only one ASP request will enter the session at each time. This avoids the problem of multithreading when accessing the session object. Unfortunately, as a result, all pages in the framework set are serialized, one by one, rather than at the same time. In this way, you may have to wait a long time to get all the framework content. This means that if some framework pages do not trust the session, you must use
@ Enablesessionstate = false
The Command tells ASP.

As an alternative to session objects, there are many ways to manage session states. When the number of states is small (less than 4 kb), we recommend that you use cookies, querystring variables, and hidden variables. For a large amount of data, such as shopping carts, using backend databases is the most appropriate choice. There is a lot of information about the Status Management Technology in the Web Server field. For more information, see session status ).

Tip 7: encapsulate code in a COM Object

If you have many vbscripts or jscripts, you can often improve their performance by moving the code to compiled COM objects. Compiled code usually runs faster than interpreted code. Compiled COM objects can access other COM objects through "Early binding". This method of calling the COM Object method is more effective than the "later binding" used by the script.

Encapsulating code in a COM object has the following benefits (beyond performance ):

COM object is a good way to separate the expression logic from the business logic.
The COM Object enables code reuse.
Many developers have found that code written in VB, C ++, or Visual J ++ is easier to debug than ASP.
COM objects have some disadvantages, including the initial development time and different programming skills. It should be warned that encapsulating a "small" ASP may cause performance degradation, rather than improving. This usually happens when a small amount of ASP code is encapsulated into a COM object. At this time, the overhead of creating and calling COM objects exceeds the benefits of compiled code. How to combine ASP scripts and COM Object code to produce the best performance is still to be tested. Note that Microsoft has greatly improved script and ADO performance in Windows 4.0/IIS 4.0 compared with Windows NT (r) 2000/IIS 5.0. In this way, the performance advantage of compiled code on ASP code has been reduced with the introduction of IIS 5.0.

For more information about the advantages and disadvantages of using COM objects in ASP, see ASP Component standards and programming distributed applications with COM and Microsoft Visual Basic 6.0 ). If you do deploy COM components, it is very important to perform strength tests on them. In fact, all ASP applications should undergo a strength test as a formal process.

Tip 8: Get resources later and release resources earlier

This is a trick. Generally, it is better to get resources later and release the resources earlier. These resources include COM objects, file handles, and other resources.

ADO connection and record set are the primary goals of this optimization. When you have used the record set, that is, after printing a table with its data, release it immediately instead of waiting until the end of the page. Set your VBScript variable
Nothing
Is the best practice. Do not leave the record set out of scope. At the same time, any related command or connection object should be released. (Do not forget to call the record set or "connection"
Close ()
, When you set them
= Nothing
Before .) This will shorten the time span for the database to adjust resources for you and release the database connection to the connection pool as quickly as possible.