24 ASP tips for improving performance and styles

Introduction

Tips 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 web server disk

Tip 4: Avoid cache of non-flexible components in Application or Session objects

Tip 5: Don't cache database connections in Application or Session objects

Tips 6: Use Session Object

Tip 7: Encapsulate code in COM object

Tips 8: Get resources later and release resources early

Tip 9: Execution outside the process will sacrifice reliability

Tip 10: Explicitly use options

Tips 11: Use local variables in subroutines and functions

Tips 12: Copy common data to script variables

Tip 13: Avoid redefining arrays

Tips 14: Use Response Buffer

Tips 15: Batch embedded scripts and statements

Tips 16: Use before starting a long task

Tip 17: Use <OBJECT> to tag instantiate objects

Tip 18: TypeLib binding using ADO objects and other components

Tips 19: Utilize browser verification capabilities

Tips 20: Avoid string concatenation in loops

Tips 21: Enable browser and proxy caching

Tips 22: Use as much as possible Substitute

Tips 23: Add a slash at the end of the directory URL

Tips 24: Avoid using server variables

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

Introduction

Performance is a feature. You need to pre-design performance, or rewrite the application later. In other words, what are good strategies for maximizing the performance of Active Server Pages (ASP) applications?

This article provides many tips for optimizing ASP applications and the "Visual Basic(R) Script Editor (VBScript). Many pitfalls and flaws are discussed. The suggestions listed in this article have been tested on and on other sites and are working properly. This article 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 usually depends more than just on the ASP code itself. We do not want to include all the wise quotes in one article, and only list performance-related resources at the end. These links include ASP and non-ASP topics, including "ActiveX(R) Data Object (ADO), "Component Object Model (COM), database, and "Internet Information Server (IIS)" configurations. These are the links we like - please follow them.

Tips 1: Cache common data on a web server

A typical ASP page retrieves data from a backend database and converts the results to Hypertext Markup Language (HTML). Regardless of the speed of the database, it is much faster to retrieve data from memory than to retrieve data from a backend database. Reading data from a local hard drive is also often much faster than retrieving data from a database. Therefore, performance can often be improved 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 properly, you will see a surprising improvement in performance. To make the cache work, it must maintain frequently reused data, and recalculating this data is expensive or relatively expensive. If the cache is full of junk data, it is a waste of memory.

Data that does not change frequently is also cached candidate data, because you don't have to worry about synchronization between the data and 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 instead of the data itself. If ASP pages do not change frequently and the caching is very expensive (for example, the entire product catalog), consider pre-generated HTML instead of redrawing each time you request.

Where should the data be cached and what caching strategies are there? Data is often cached on Web server memory or on 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 convenient containers for caching data in memory. You can either assign data to Application objects or Session objects, which will be retained in memory in HTTP calls. Session data is stored by user, while Application data is shared among all users.

When to load data into Application or Session? Typically, data is loaded when Application or Session starts. To load data when Application or Session starts, add the corresponding code in the following two functions:
Application_OnStart()
or
Session_OnStart()
. These two functions should be located in ; if not, you can add these functions. It is also possible to load data the first time you need it. To do the above, add some code (or write reusable script functions) to the ASP page that checks whether the data exists and loads the data if it does not exist. Here is an example of a classic performance technique called slow computing - no calculations are done until you do need it. Please see the example:

<%
Function GetEmploymentStatusList
Dim d
d = Application("EmploymentStatusList")
If d = "" Then
‘' FetchEmploymentStatusList function (not displayed)
‘' Take out data from DB and return to the array
d = FetchEmploymentStatusList()
Application("EmploymentStatusList") = d
End If
GetEmploymentStatusList = d
End Function
%>

Similar functions can be written for each piece of data required.

In what format should the 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 will store the contents of the ADO record set in one of these variable types. To get data derived from the ADO record set, you can manually copy the data into a VBScript variable one field at a time. Using an ADO record set retention function GetRows(), GetString(), or Save() (ADO 2.5) is faster and easier. The complete and detailed content is beyond the scope of this article. The following demonstration function is used
GetRows()
Returns an array of recordset data:

‘' Get the record set and return it as an array
Function FetchEmploymentStatusList
Dim rs
Set rs = createObject("")
"select StatusName, StatusID from EmployeeStatus", _
"dsn=employees;uid=sa;pwd=;"
FetchEmploymentStatusList = () ‘' Return data as an array

Set rs = Nothing
End Function

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

‘' Get the record set and return as the "HTML Options" list
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = createObject("")
"select StatusName, StatusID from EmployeeStatus", _
"dsn=employees;uid=sa;pwd=;"
s = "<select name=""EmploymentStatus">" & vbCrLf
Set fldName = ("StatusName") ‘' ADO field binding
Do Until
‘' The following line violates the string connection.
‘' But this is OK because we are building a cache
s = s & " <option>" & fldName & "</option>" & vbCrLf

Loop
s = s & "</select>" & vbCrLf

Set rs = Nothing ‘' See Early Release
FetchEmploymentStatusList = s ‘' Return data as a string
End Function

In normal cases, the ADO record set itself can be cached in the Application or Session scope. There are two warnings:

ADO must be a tagged free thread
A disconnected record set must be used.
If these two requirements are not guaranteed to be met, do not cache the ADO record set. In the following non-flexible components and the non-cache connection tips, we will discuss the dangers of storing COM objects in the Application or Session scope.

If you store data in the Application or Session scope, the data will remain there until it is changed in the program, the Session expires, or the web application restarts. How to deal with data needing updates? To manually force update application data, you can call update ASP pages for data that are only allowed to be accessed by administrators. In addition, the data can be automatically refreshed periodically through functions. The following example stores a timestamp with cached data, refreshing the data after a specified time interval.

<%
‘' No error handling is shown...
Const update_INTERVAL = 300 ‘' Refresh time interval, measured in seconds

The function returns the list of employment statuses
Function GetEmploymentStatusList
updateEmploymentStatus
GetEmploymentStatusList = Application("EmploymentStatusList")
End Function

‘'Cache data is updated regularly
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. This is OK, but
‘' It just generates several unnecessary fetch commands (there is a workspace here)

‘' FetchEmploymentStatusList function (not displayed)
‘' Get data from DB and return an array
d = FetchEmploymentStatusList()

‘' Update the Application object. use ()
‘' to ensure consistent data

Application("EmploymentStatusList") = d
Application("Lastupdate") = CStr(Now)

End If
End Sub

For other examples, see the Fastest List Box with Application Data (English).

Note that caching large arrays in Session or Application objects is not the best way to do it. Before accessing array elements, the syntax of the scripting language requires the creation of a temporary copy of the entire array. For example, if an array of strings that map the U.S. zip code to a local weather station is cached in an Application object that has 100,000 elements, ASP must copy all 100,000 weather stations into a temporary array before finding a string. In this case, it is better to build a custom component with a custom method to store the weather station - or use a dictionary component.

Please do not throw away the children together when pouring the bath water. A new annotation to this view is that the array provides quick search and storage of adjacent keys in memory - data pairs. Index dictionaries are slower than index arrays. You should choose a data structure that provides the best performance based on the situation.

Tip 3: Cache data and HTML on web server disk

Sometimes, too much data cannot be cached in memory. "Overy" is a qualitative judgment; it depends on the amount of memory to be consumed, as well as the number of cached items and the frequency of searching these items. In short, if there is too much data to be cached in memory, consider cache data on the web server's hard disk in the form of text or XML files. You can combine cache data on disk and cache data in memory to establish an optimal cache policy for the site.

Note that when measuring the performance of a single ASP page, retrieving data on disk is not necessarily faster than retrieving data from a database. However, caches reduce the load on the database and network. In high load situations, this will significantly increase overall traffic. Caches the results of a query when the query costs are high, and caching is very effective, such as multi-table federation or complex stored procedures, or caches large result sets. As usual, test the competition plan.

ASP and COM provide several tools for building disk caching schemes. Save() and Open() functions of ADO recordsets, saving and loading recordsets on disk. You can use these methods to rewrite the example code in the Application Data Caching Tips above, replacing the code that writes data to the Application object with the Save() file.

There are some other components that handle files:

Enables you to create, read, and write files.
MSXML is a Microsoft(R) XML parser provided with Internet Explorer, which supports saving and loading XML documents.
The LookupTable object (example used on MSN) is a good choice for loading simple lists from disk.
Finally, consider cached representations of data on disk, not the data itself. Prefabricated HTML can be stored on disk as .htm or .asp files; hyperlinks can point directly to these files. You can use Internet distribution capabilities of commercial tools such as XBuilder or Microsoft(R) SQL Server to automate the HTML generation process. Alternatively, you can #include the HTML snippet into the .asp file. You can also use FileSystemObject to read HTML files from disk or use XML for early adjustments (in English).

Tip 4: Avoid cache of non-flexible components in Application or Session objects

While it is a good idea to cache data in an Application or Session object, caching COM objects can have serious flaws. Embedding common COM objects into Application or Session objects is often attractive. Unfortunately, many COM objects, including those written in Visual Basic 6.0 or earlier, can cause serious bottlenecks when stored in Application or Session objects.

In particular, any non-flexible component will cause performance bottlenecks when caching in Session or Application objects. Flexible components are marked as
ThreadingModel=Both
component (it gathers free thread aggregate (FTM)) or marked as
ThreadingModel=Neutral
Components (the "neutral" model added in Windows(R) 2000 and COM+.) The following components are non-flexible:

Free-threaded components (unless they gather FTMs).
Unit thread component.
Single-threaded component.
Configured components (Microsoft Transaction Server (MTS)/COM+ libraries and server packages/applications) are non-flexible components unless they are "neutral" threaded. Unit thread components and other non-flexible components are best suited for working on page scope (that is, they are created and destroyed on a single ASP page).

In IIS 4.0, marked as
ThreadingModel=Both
The components are considered flexible. In IIS 5.0, this is not enough. Components must not only be marked Both, but also have to aggregate FTMs. The Flexibility article explains how to make C++ components written in "Active Template Library" aggregate FTMs. Note that if the component caches interface pointers, these pointers must themselves be flexible or must be stored in the "COM Global Interface Table (GIT). If the Both thread component cannot be recompiled so that it aggregates FTM, you can mark the component as
ThreadingModel=Neutral
. Additionally, if you do not want IIS to perform flexibility checks (this is desired that non-flexible components can be stored in Application or Session scopes), you can set it in metabase
AspTrackThreadingModel
for
True
. No claiming changes
AspTrackThreadingModel
。

If you try to store it in an Application object

IIS 5.0 will generate an error for the created non-flexible component. Can be used in
<object runat=server scope=application ...>
Solve this problem, but do not advocate doing so, as this will lead to pooling and serialization, as explained below.

What errors will happen if non-flexible components are cached? A non-flexible component cached in a Session object will "lock" the session to an ASP worker thread. ASP maintains a pool of worker threads that serve requests. Typically, new requests are handled by the first available worker thread. If the Session is locked to a thread, the request will have to wait for the thread it is associated to become available. For example: You enter a supermarket, select some food, and then pay the payment at the 3rd receipt. From then on, whenever you buy food in this supermarket, you have to always pay at the 3rd receipt station, even when there are fewer or no one in other receipt stations.

Storing non-flexible components in Applicaton scope can even have a more severe impact on performance. ASP will have to create dedicated threads to run non-flexible, Applicaton-scoped components. This will result in two consequences: all calls have to be pooled to the thread, and all calls are serialized. Summarizes: parameters have to be stored in a shared area of memory; expensive context switching is performed on the dedicated thread; component methods are executed; results are collected into the shared area; and control is returned to the original thread through another expensive context switching. Serialization means that all methods must be run one by one (only one method can be run at the same time). It is impossible for two different ASP worker threads to execute methods on shared components at the same time. This will kill the parallelism mechanism, especially on multiprocessor computers. Even worse, all non-flexible, Application scoped components will share a thread ("Host STA"), so the impact of serialization is even more severe.

Confused? Below we propose several general rules. If you are writing objects in Visual Basic (6.0) or earlier, do not cache them in Application or Session objects. If you don't know the thread model of the object, don't cache it. Instead of cache non-flexible objects, create and release them on each page. Objects will run directly on the ASP worker thread, so that no aggregate or serialization will occur. If the COM objects are running in the IIS box, and if they do not take a long time to initialize and cancel, performance will be sufficient. Note that do not use single-threaded objects using this method. Beware: VB can create single-threaded objects! If you must use single-threaded objects in this way, such as Microsoft Excel spreadsheets, 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 a file, which is usually located in the following directory: \\Program Files\Common\System\ADO.

Warning: If you are using Microsoft Access as your database, you should not mark ADO as a free thread. Typically, the ADO record set must also be disconnected, and it might be better not to cache the record set if you can't control the ADO configuration of the site (for example, you are an independent software vendor [ISV], selling the web application to the customer, and then they will manage their own configuration).

Dictionary components are also flexible objects. LookupTable loads its data from a data file, and it is useful for combo box data and configuration information. The PageCache object from Duwamish Books provides directory semantics, which is the same as the Caprock Dictionary. These objects or their derived objects can form the basis of an effective caching strategy. Note that objects are not flexible and should not be stored in Application or Session scopes.

Tip 5: Don't cache database connections in Application or Session objects

Caching ADO connections is usually a bad strategy. If a Connection object is stored in Application and used on all pages, all pages will compete for the connection. If the Connection object is stored in the ASP Session object, a database connection is created for each user. This ruins the benefits of connection pooling and puts unnecessary pressure on the web server and database.

Instead of caching database connections, create and cancel the ADO object on each ASP page that uses ADO. This is an efficient approach because IIS has a built-in database connection pool. To be more precise, IIS automatically enables OLEDB and ODBC connection pooling. This ensures that creating and unconnecting on each page will be valid.

Since the connected records store references to database connections in the cluster, the connected recordset should not be cached in the Application or Session object. However, a disconnected record set can be safely cached because it does not contain references to its data connection. To disconnect the record set, perform two steps:

Set rs = ("")
= adUseClient ‘' Step 1

‘' Insert a record set with data
strQuery, strProv

‘' Now disconnect the record set from the data provider and the data source
= Nothing ‘' Step 2

For more information about connection pooling, see ADO and SQL Server (English) References.

Tips 6: Use Session Object

After affirming the advantages of caching in Applications and Sessions, we recommend that you avoid Session objects. Here we will talk about Sessions' several drawbacks when used in busy sites. Busy usually means that the site requests hundreds of pages per second or has thousands of users at the same time. This technique is even more important for sites that must scale horizontally, i.e. those that utilize multiple servers to adapt to load or perform fault tolerance. For smaller sites, such as intranet sites, the convenience of Sessions is also worth it compared to the overhead.

For refurbishment, ASP automatically creates a session for each user who accesses the web server. Each session has approximately 10 KB of memory overhead (the highest of any data stored in the session) and makes all requests a little slower. Session remains active until a configurable timeout (usually 20 minutes) is reached.

The biggest problem with Session is not performance but scalability. Sessions cannot span web servers; once a session is created on a server, its data remains there. This means that if you use Sessions in the web realm, you will have to design a policy for each user's requests so that you always direct those requests to the server where the user's session resides. This is called "sticking" users to a web server. The term "sticky conversation" comes from this. Since the Session is not kept to disk, users who are "sticked" will lose their Sessions status when the web server crashes.

Strategies used to implement sticky sessions include hardware and software solutions. Network load balancing solutions such as Windows 2000 Advanced Server and Cisco's "local pointer" solutions can implement sticky sessions at the expense of some scalability. These solutions are not perfect. We do not argue that you are now overturning your software solution (we used to check the scheme with ISAPI filters and URL straightening).

Application objects cannot span servers either; if you need to share and update Application data within the web realm, you need to use a backend database. But read-only Application data is still useful in the web world.

If it is just for increasing uptime (for handling failover and server maintenance), most sites that perform important tasks will require at least two web servers to be deployed. So, when designing applications that perform important tasks, you will need to implement "sticky sessions" or simply avoid Sessions and any other state management techniques that store user state on a single web server.

If you are not currently using Sessions, make sure to turn them off. This operation can be performed for the application through the Internet Service Manager (see the ISM documentation). If you decide to use Sessions, there are several ways to minimize the impact on performance.

Content that does not require Sessions (such as "Help" screens, visitor areas, etc.) can be moved to a separate ASP application with Sessions closed. You can prompt ASP page by page: You do not need a Session object in a given page; use the following command located at the top of the ASP page:

<% @EnableSessionState=False %>

A good reason to use this directive is that Session creates interesting problems for framework sets. ASP guarantees that only one request from a Session is executed at any time. This ensures that if the browser requests multiple pages for a user, only one ASP request will enter the Session at each moment; this avoids multithreading issues when accessing Session objects. Unfortunately, as a result, all pages in the framework set are drawn serially, one after another, not at the same time. This way, users may have to wait a long time to get all the framework content. This means: If some framework pages do not trust the Session, be sure to use it
@EnableSessionState=False
Instructions tell the ASP.

As an alternative to using Session objects, there are many ways to manage Session state. For cases where the number of states is small (less than 4 KB), it is generally recommended to use cookies, QueryString variables, and hidden forms of variables. For larger amounts of data, such as shopping carts, using a backend database is the most suitable choice. There is already a lot of information about state management technology in the field of web servers. For more information, see Session Status (English).

Tip 7: Encapsulate code in COM object

If you have a lot of VBScript or JScript, you can often improve their performance by moving your code to compiled COM objects. Compiled code usually runs faster than interpreted code. Compiled COM objects can access other COM objects through "early binding", a means of calling COM object methods is more effective than the "late binding" used by scripts.

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

COM objects are a good way to separate expression logic from business logic.
The COM object has code reuse enabled.
Many developers find that code written in VB, C++, or Visual J++ is easier to debug than ASP.
COM objects have some disadvantages, including initial development time and the need for different programming skills. It is important to warn you that encapsulating a "small" amount of ASP may lead to performance degradation rather than improvement. Usually, this 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. As for how ASP scripts and COM object codes are merged to produce optimal performance, it remains to be tested. Note that Microsoft has greatly improved scripting and ADO performance in Windows 2000/IIS 5.0 compared to Windows NT(R) 4.0/IIS 4.0. In this way, the performance advantages of compiled code on ASP code have been degraded with the introduction of IIS 5.0.

For more discussion of the advantages and disadvantages of using COM objects in ASP, see ASP Component Guidelines and Programming Distributed Applications with COM and Microsoft Visual Basic 6.0 (English). If you do deploy COM components, it is very important to test them in strength. In fact, all ASP applications should be tested in intensity as formal processes.

Tips 8: Get resources later and release resources early

This is a little trick. Generally, it is best to obtain resources later and release resources early. These resources include COM objects, file handles, and other resources.

ADO connections and record sets are the primary goals of this optimization. When you have finished using 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 to
Nothing
It is the best way to do it. Don't simply distract the record set. At the same time, any relevant Command or Connection objects should be released. (Don't forget to call recordsets or "connections"
Close()
, set them to
= Nothing
Before. ) This will shorten the time span of the database that the resource must be adjusted for you and release the database connection to the connection pool as quickly as possible.

Tip 9: Execution outside the process will sacrifice reliability

ASP and MTS/COM+ have configuration options that allow you to trade reliability for performance. This exchange should be understood when creating and deploying applications.

ASP Options

ASP applications can be configured to run in one of three ways. The term "isolation level" is introduced in IIS 5.0 to describe these options. The three isolation level values are low, medium and high:

Low-level isolation. This isolation level is supported in all versions of IIS and is the fastest. It executes ASP in the main IIS process. If the ASP application crashes, IIS will also crash. (To restart IIS under IIS 4.0, the Web site administrator needs to use tools such as InetMon to monitor the site, and if the server fails, a batch file will be run to restart the server. IIS 5.0 introduces a reliable restart, which will automatically restart the failed server.)
Intermediate isolation. IIS 5.0 introduces this new isolation level, called out-of-process, because ASP runs outside of IIS processes. In intermediate isolation, all ASP applications configured to run as "intermediate" will share a single process space. This reduces the number of processes required to run multiple off-process ASP applications on one server. Intermediate is the default isolation level in IIS 5.0.
Advanced isolation. Supported in IIS 4.0 and IIS 5.0, advanced isolation is also out of process. If ASP crashes, the web server does not crash. The ASP application will automatically restart on the next ASP request. Using Advanced Isolation, each ASP application configured to run as Advanced will run in its own process space. This protects ASP applications from interfering with each other. Its disadvantage is that it requires establishing independent processes for each ASP application. There is a lot of overhead when you need to host more than a dozen applications on one server.
So, which option is the best? In IIS 4.0, running applications outside of the process can greatly affect performance. In IIS 5.0, a lot of work has been done to minimize the performance impact of running ASP applications off-process. In fact, in most tests, ASP off-process applications in IIS 5.0 run faster than in-process applications in IIS 4.0. In any case, in-process (low isolation level) still produces the best performance on both platforms. However, if you have relatively low hit rate or have a low maximum throughput, choosing a low isolation level won't have much benefit. So, unless you need to process hundreds or thousands of pages per second per web server, there is no need to choose a low isolation level. Similarly, you should test multiple configurations and determine which situation is best for you.

Note: When you run ASP applications outside of the process (intermediate or advanced isolation), they will run in MTS on NT4, and on Windows 2000, they will run in COM+. That is, they run in NT4, and on Windows 2000, they run in . In Task Manager, you can see these running processes. You can also see how IIS configures an MTS package or COM+ application for an off-process ASP application.

COM Options

The COM component also has three configuration options, although not exactly similar to the ASP option. The COM component can be: "not configured", configured as a "library application", or configured as a "server application". "Not configured" means not registering components with COM+. Components will run in the caller's process space, that is, they are "in-process". "Library Applications" are also in-process, but benefit from COM+ services, including security, transactional and environmental support. The "server application" is configured to run in its own process space.

You may see that unconfigured components have slightly more advantages than library applications. You may also see that "library applications" have great performance advantages over "server applications". This is because the "library application" runs in the same process as the ASP, while the "server application" runs in its own process. The overhead of internal process calls is much greater than that of in-process calls. Moreover, when passing data between processes (such as record sets), all data must be copied between the two processes.

shortcoming! When using the "COM Server Application", if you want to pass objects between ASP and COM, make sure that the objects implement "Solved by Value", i.e. MBV. An object that implements an MBV copies itself from one process to another. This is better than the other way, where the object stays in the process that created it, while other processes repeatedly call the process that created the object. The disconnected ADO recordset will be aggregated by value, while the connected recordset will not. MBV is not implemented and will not be passed between processes. Finally, what I want to tell VB programmers is: MBV does not pass parameters
ByVal
Obtained. MBV is implemented by the original component creator.

what to do?

If you want to complete your configuration with a reasonable exchange of performance and reliability, our recommendations are as follows:

On IIS 4.0, use the low isolation level of ASP and use the "MTS Server Package".
On IIS 5.0, use the medium isolation level of ASP and use the "COM+ Library Application".
These are very general guidelines; companies are usually allowed to run ASP at medium or high isolation levels, while single-purpose web servers can run at low isolation levels. Please weigh the trade-offs and decide on the configuration that meets your needs.

Tip 10: Explicitly use options

Use explicitly in .asp files
Options Explicit
. This directive placed at the beginning of the .asp file forces the developer to declare all variables to use. Many developers think this helps debug your application because it avoids accidentally creating new variables by typing the variable name incorrectly (e.g.
MyXLMString=...
Instead
MyXMLString=)
。

Perhaps more importantly, declared variables are faster than undeclared variables. In fact, when the script is run, it is referenced by name every time an undeclared variable is used. The declared variables are assigned a sequence number at compile or runtime. In this way, declared variables are referenced according to this sequence number. because
Options Explicit
Force variable declarations, thus ensuring that all variables are declared for quick access.

Tips 11: Use local variables in subroutines and functions

Local variables are variables declared in subroutines and functions. In subroutines and functions, local variable access is faster than global variable access. Using local variables can also make the code clearer, so use local variables whenever possible.

Tips 12: Copy common data to script variables

When accessing COM in ASP, commonly used object data should be copied into script variables. This will cut the call to the COM method, which is relatively expensive compared to accessing script variables. This technique can also cut down on expensive searches when accessing Collection and Dictionary objects.

Typically, if you intend to access object data multiple times, put the data into a script variable. The main goal of this optimization is the Request variable (Form and QueryString variables). For example, your site might pass a QueryString named UserID. Assume that the UserID variable is referenced 12 times in a specific page. Please do not call
Request("UserID")
12 times, and at the beginning of the ASP page, the UserID is assigned to a variable. Then use the variable in the page. This will save 11 COM method calls.

In practice, accessing COM properties or methods hides complex processes and a lot of overhead. Here is an example, it's just some pretty normal code (grammatically speaking):

= (1)
If = Then ‘' ...

When you run this code, the following events will occur:

variable
Foo
Resolved as a global variable.
variable
bar
Resolved as
Foo.
members of the This will produce a COM method call.
variable
blah
Resolved as

members of the This will also produce a COM method call.
variable
qaz
Resolved as

members of the Yes, this will also produce a COM method call.
Call
(1)
. Another COM method call is generated. Do you understand this picture?
Execute steps 1 to 3 and parse again
baz
. The system does not know how to call it
qaz
Whether to change the object model, so steps 1 to 3 must perform the parsing again
baz
。
Will
baz
Resolved as

members of the Perform attribute placement.
Perform steps 1 to 3 again and parse
zaq
。
Perform steps 1 to 3 again and parse
abc
。
As can be seen, it is very terrible inefficiency (and very slow). The quick way to write this code in VBScript is:

Set myobj = ‘'Do a parse of blah
= (1)
If = Then ‘'...

If you are using VBScript 5.0 or later, it is available
With
Let's write this code with a statement:

With
.baz = .qaz(1)
If .zaq = .abc Then ‘'...
...
End With

Please note that this technique works equally for VB programming.

Tip 13: Avoid redefining arrays

Try to avoid
Redim
Array. From a performance-conscious point of view, if the computer is limited by physical memory, it is best to set the dimension of the array to the worst solution at the beginning - instead of setting the dimension to the best solution, redefine the dimension as needed. This does not mean that you should allocate too much memory even though you know that you don't need that much.

The following code shows that you use it unnecessary
Dim
and
Redim
Let's solve it.

<%
Dim MyArray()
Redim MyArray(2)
MyArray(0) = "hello"
MyArray(1) = "good-bye"
MyArray(2) = "farewell"
...
‘' In some other code, here you don't need more space, then...
Redim Preserve MyArray(5)
MyArray(3) = "more stuff"
MyArray(4) = "even more stuff"
MyArray(5) = "yet more stuff"
%>

A better approach is to just start
Dim
The array is of the correct size (5 in this case), not
Redim
Array, add the array. This may waste a little memory (if all elements are not exhausted), but what you get is speed.

Tips 14: Use Response Buffer

You can buffer the entire page worth output by opening the Response Buffer. This minimizes the amount of data written to the browser, thereby improving overall performance. Each write will have a lot of overhead (including IIS and the amount of data sent over the cable), so the less you write, the better. TCP/IP's work efficiency is significantly higher when sending a small number of large data blocks than when sending a large number of small data blocks, because of its low-speed startup and Nagling algorithm (used to minimize network blocking).

There are two ways to turn on response buffering. The first is to use the "Internet Service Manager" to turn on response buffering for the entire application. This is the recommended method, in IIS 4.0 and IIS 5.0, by default, response buffering is turned on for new ASP applications. The second type is to enable response buffering by placing the following lines of code pages page by page:

<% = True %>

This line of code must be executed before any response data is written to the browser (that is, before any HTML appears in the ASP script and any cookies are used

before the collection is set). Generally, it is best to turn on response buffering for the entire application. This allows the omission of lines of code in each page above.

A common problem with response buffering is that users feel that the ASP page is dull (although overall response time improves) because they need to wait until the entire page is generated before they can see the page. For long-running pages, you can set it
= False
Turn off response buffering. But, a better strategy is to use

method. This method refreshes all HTML drawn into the browser by ASP. For example, after drawing 100 rows of a table with 1,000 rows, ASP can call

Forces the result to the browser; this allows the user to see the first 100 rows before the remaining rows are ready. This technology gives you two unparalleled goodies – a combination of response buffering and step-by-step display of data in your browser.

(Note that in the above example of the 1,000 row table, many browsers, do not start drawing tables until they see the </table> end tag. Please check the support of the target browser. To resolve this issue, split the table into multiple tables with fewer rows and call after each table

. New versions of Internet Explorer draw the table before the table is fully downloaded, especially if the column width of the specified table is drawn faster; this avoids forcing Internet Explorer to calculate the column width by measuring the contents of each cell. )

Another common problem with response buffering is the use of large amounts of memory on the server when generating large pages. For this problem, in addition to the skills to generate large pages, it can also be used skillfully

Let's solve it.

Tips 15: Batch embedded scripts and statements

VBScript Syntax
<% = expression %>
Will"
expression
The value of " is written to the ASP output stream. If the response buffer is not turned on, each sentence of these statements will cause data to be written to the browser through the network, in the form of many small packages. This is very slow. Also, interpreting a small amount of scripts and HTML will result in switching between the script engine and HTML, which also degrades performance. So, use the following tip:

A call to replace the embedded dense combination expression. For example, in the following example, each row and each field has a write to the response stream, and each row has many switching between VBScript and HTML:

Below is a more efficient code, with a write to the response stream in each line. All code is included in a VBScript block:

<table>
<%
For each fld in
("<th>" & & "</th>" & vbCrLf)
Next
While Not
("<tr>")
For Each fld in %>
("<td>" & & "</td>" & vbCrLf)
Next
"</tr>"
Wend
%>
</table>

This technique works more when response buffering is disabled. It's better to enable response buffering and then observe the batch processing

Whether it is helpful for performance.

(In this special case, the nested loop of the body of the table is constructed (
While Not ...
) can be replaced by carefully constructed calls to GetString. )

Tips 16: Use before starting a long task

If users lose patience, they can give up the ASP page before starting executing their request. If they click Refresh or jump to another page on the server, there will be a new request at the end of the ASP request queue and a disconnected request in the middle of the queue. This usually happens when the server is under high load (it has a long request queue and the corresponding response time is also long), which can only make the situation worse. If the user no longer connects, there will be no point to execute the ASP page (especially low-speed, heavy-weight ASP page). Available

Attributes check this situation. If it returns
False
, it should be called

And abandon the remaining content of the page. In fact, whenever the ASP wants to execute a new request, IIS 5.0 encodes the method to check how long the request in the queue is. If it is there for more than 3 seconds, the ASP checks if the client is still connected and ends the request immediately if the client is disconnected. You can use the
AspQueueConnectionTestTime
Set, adjust the timeout of these 3 seconds.

If a page has been executed for a long time, you may also want to check at a certain interval.

. After enabling response buffering, execute at a certain time interval

, telling users what is going on is a good idea.

Note In IIS 4.0,

Will not work properly unless executed first

. If buffering is enabled, it also needs to be executed

. This is not necessary in IIS 5.0 -

Works very well. in any case,

All have some overhead, so use it only before executing an operation that takes at least 500 milliseconds (which is a long time to maintain throughput of dozens of pages per second). As a common rule, don't call it in every iteration of a tight loop, for example when drawing rows in a table, it may be called every 20 rows or every 50 rows.

Tip 17: Use <OBJECT> to tag instantiate objects

If you need to refer to objects that cannot be used in all code paths (especially server- or application-scope objects), use
<object runat=server id=objname>
Tags to declare them, not using

method.

Create the object now. If you don't use that object in the future, don't waste resources.
<object id=objname>
The tag declares objname, but in fact objname is not created at this time until its method or property is first used.

This is another example of slow calculations.

Tip 18: Use TypeLib declarations for ADO objects and other components

When using ADO, developers often include

to obtain access to different ADO constants. The file must be included in each page where you want to use these constants. This constant file is very large, adding a lot of overhead in terms of compilation time and script size to each ASP page.

IIS 5.0 provides the ability to bind to component type libraries. Allows you to reference a type library once on each ASP page and use it. Each page does not need to pay a price to compile constant files, and component developers do not have to generate VBScript #include files for use in ASP.

To access the ADO type library, put one of the following statements in .

Tips 19: Utilize browser verification capabilities

Popular browsers have advanced support for the following features, such as XML, DHTML, Java applets, and remote data services. Please try to make use of these features. All of these technologies can reduce round trips with the web server by performing client authentication and data caching. If you are running a smart browser, this browser can do some verification for you (for example, checking if the checksum of your credit card is valid before running POST). Reiterate, try to use these features. As the client-to-server round trip is reduced, the pressure on the web server will be reduced, and network traffic is reduced (although the initial page sent to the browser may be larger), all backend resources accessed by the server are also reduced. Moreover, users do not need to extract new pages frequently, so that users can feel better. This does not alleviate the need for server-side verification. Server-side verification should still be carried out frequently. This prevents bad data from the client for some reason, such as hackers, or browsers that do not run client verification programs.

Many sites are composed of HTML created independently of the browser. This often hinders developers from taking advantage of popular browser features that can improve performance. For truly high-performance sites that have to care about your browser, a good strategy is to optimize your pages for popular browsers. Using "Browser Performance Components" in ASP, it is easy to detect the functionality of the browser. Tools such as Microsoft FrontPage can help you design code that uses the desired target browser and HTML version. For a more detailed discussion, please see When is Better Worse? Weighing the Technology Trade-Offs (English).

Tips 20: Avoid string concatenation in loops

Many people create strings like this in a loop:

s = "<table>" & vbCrLf
For Each fld in
s = s & " <th>" & & "</th> "
Next

While Not
s = s & vbCrLf & " <tr>"
For Each fld in
s = s & " <td>" & & "</td> "
Next
s = s & " </tr>"

Wend

s = s & vbCrLf & "</table>" & vbCrLf
s

There are several problems with this method. First, the time taken to repeatedly connect the string grows at the rate of the quadratic curve; roughly calculated, the time taken to run the loop is proportional to the record number multiplied by the square of the number of fields. This can be clearly explained by giving a simple example.

s = ""
For i = Asc("A") to Asc("Z")
s = s & Chr(i)
Next

In the first iteration, get a string of characters
"A"
. In the second iteration, VBScript must reassign the string and copy two characters
"AB"
arrive

. In the third iteration, it must be reassigned again

and copy three characters to

. In the Nth (26th) iteration, it must reassign and copy N characters to

. It is the sum of 1+2+3+...+N, which is N*(N+1)/2 copies.

In the above record set example, if there are 100 records and 5 fields, the internal loop will be executed 100*5 = 500 times and the time it takes to complete all replication and reallocation will be proportional to 500*500 = 250,000. For a moderately sized record set, there will be many copies.

In this example, the code can be improved: the concatenation of the string will be
()
or embedded script (
<% = %>
) replaced. If the response buffer is turned on, this operation will be very fast because

Just add data to the end of the response buffer. No redistribution anymore, so it is very effective.

Especially when converting ADO recordsets to HTML tables, consider using GetRows or GetString.

If you use JScript to connect strings, it is highly recommended to use them
+=
operator;
s += "A certain string",
Instead
s = s + "some string"
。

Tips 21: Enable browser and proxy caching

By default, ASP disables cache in browsers and proxy. This would make sense because ASPs are born dynamic with potentially time-sensitive information. If there is a page that does not require refreshing each view, browser and proxy caching should be enabled. This allows the browser and proxy to use a cached copy of a certain page for a certain period of time, and the length of this time can be controlled. Cache can significantly reduce server load and make users feel better.

Which dynamic page can be cached? Give an example:

Weather page, updated every 5 minutes.
List the home page of the news or the home page of the news release, updated 2 times a day.
Public fund operation list, basic statistics updated 1 time every hour.
Note that using browser or proxy cache, only few hits are logged onto the web server. If you want to accurately measure all page viewing or post ads, you may not like using browser and proxy cache.

Browser cache is controlled by the HTTP expiration title sent to the browser by the web server. ASP provides two mechanisms for sending titles. To set the page to expire after a certain number of minutes in the future, set

property. The following example notifies the browser: Content expires after 10 minutes:

<% = 10 %>

set up

Negative or 0 disable cache. Be sure to use a larger negative number, such as -1000 (greater than one day) to overcome the difference between the server clock and the browser clock. The second attribute

, allows setting the specified time for content expiration:

<% = #May 31,2001 13:30:15# %>

If you do not want to set the expiration time using the Response object, you can write the <META> tag to HTML, usually inside the <HEAD> of the HTML file. Some browsers will respond to this instruction, but the proxy will not.

Finally, you can identify whether the content is valid for the HTTP proxy cache. Please use

property. Set the property to "Public" to allow the proxy to cache content.

<% = "Public" %>

By default, this property is set to "Private". Note that proxy caching should not be enabled for pages that display data for a particular user, because proxy may serve user pages belonging to other users.

Tips 22: Use as much as possible Substitute

Notify the browser to request a different page. This function is often used to redirect users to login or error pages. Since redirect forces a new page request, the browser must make two round trips to the web server, and the web server must handle additional requests. IIS 5.0 introduces a new function.

, this function executes a different ASP page sent to the same server. This avoids additional round trips from the browser to the web server, improving overall system performance while improving response time to users. Please see the new direction in the redirection (in English), which discusses

and

。

You can also view a complete list of new features in Leveraging ASP in IIS 5.0 and ASP 3.0. (English)

Tips 23: Add a slash at the end of the directory URL

The relevant trick is to add a slash at the end of the URL pointing to the directory.
(/)
. If the slash is omitted, the browser will make a request to the server, only notifying it that it is looking for a directory. The browser then makes a second request, adds a slash at the end of the URL, and the server responds with the default document for that directory, or if there is no default document and directory browsing is enabled, the directory list is responded. Adding a slash saves the first useless round trip. For user-friendliness, maybe you want to omit the slash at the end of the displayed name.

For example, write:

<a href="/workshop/" title="MSDN Web
Workshop">/workshop</a>

It also works with URLs pointing to the home page of the Web site: Please use the following: <a href="/">, and do not use <a href="">.

Tips 24: Avoid using server variables

Accessing the server variable will cause the Web site to make a special request to the server and then collect all the server variables, not just the one you need. It's like retrieving a special piece of information from a folder in a moldy attic. When you want a piece of information, you must first go to the attic to obtain the folder before accessing the information. This is the same as when the performance access occurs when the server variable is requested. Subsequent access to other server variables will not cause performance access.

Never access a failed Request object (for example, Request("Data") ). There are implicit calls to items not in , , or .

Collections are much slower than other collections.