Tips for improving ASP performance and appearance (I)

Tips for improving ASP performance and appearance (I)
[Date: 2006-10-10] [Font: large, medium, and small]

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.

 

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 add the functions in global. Asa if they are not needed for the first time. 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. For example, 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. 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. It is not a good practice to cache large arrays in session [/B] or application objects. Before accessing any element of the array, the syntax of the script language requires that the entire array be copied temporarily. 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 in memory, as well as the number of projects to be cached and the frequency of retrieving these items. 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 & reg; 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 Microsoft & reg; SQL Server & #8482; 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.
Tip 4: Avoid caching non-agile components in application or session objects
Although caching data in application or session objects is a good practice, caching COM objects has a serious trap. In general, people tend to cache frequently used COM objects to application or session objects. Unfortunately, many COM objects (including all ession objects in Visual Basic 6.0 or earlier versions. Unfortunately, many COM objects (including all objects written in Visual Basic 6.0 or earlier) may cause serious bottlenecks when stored in application or session objects. Specifically, when any inagile component is cached in the session or application object, it will cause a performance bottleneck. An agile component is a component marked as threadingmodel = both, which aggregates free-threaded virtualer (FTM); or is marked as a threadingmodel = neutral component. (The neutral model is a new model for Windows & reg; 2000 and COM + .) The following components are not agile:
Free-threaded components (unless they aggregate FTM ).
Unit thread component.
Single-threaded components.
The configured components (Microsoft Transaction Server (MTS)/COM + Library and server packages/applications) are not agile unless they are neutral threads. Unit thread components and other non-agile components are the most suitable in the scope of the page (that is, they are created and destroyed on a single ASP page ). In IIS 4.0, Components Marked as threadingmodel = both are considered agile. In IIS 5.0, this is not enough. The component must not only be marked with both, but also be clustered with FTM. The article on Agility describes how to aggregate FTM with C ++ components written in the Active Template Library. Note that if the component caches interface pointers, the pointers must be agile or stored in the com shared interface table (GIT. If you cannot re-compile the both thread component to aggregate FTM, you can mark the component as threadingmodel = neutral. Alternatively, if you do not want IIS to perform a agility check (therefore, you can allow non-agile components to be stored in the application or session scope ), you can set the asptrackthreading model to true in the configuration database. We do not recommend that you change the asptrackthreadingmodel. If you want to store non-agile components created with server. Createobject in the Application object, IIS 5.0 will have an error. You can avoid this error in global. Asa, but we do not recommend this because it will result in collection and serialization, which will be described below. What will happen if you cache non-agile components? The slow set and serialization are described below. What will happen if you cache non-agile components? Slow down
Non-agile components in the session object lock the session to the ASP worker thread. ASP maintains a worker thread pool to process requests. Generally, a new request is always processed by the first available worker thread. If the session is locked on a thread, the request must wait until the relevant thread is available.
The impact of Storing non-agile components in the application scope on performance is even worse. ASP must create a special thread to run and store
Non-agile components in application scope. There are two results: All calls must be aggregated into this thread, and all calls are lined up. "Aggregation" means that the parameters must be stored in the shared area of the memory; execute a context switch with high overhead to a special thread; execute the component method; and collect the results to the shared area; execute another context switch with high overhead and control the return to the original thread. Serialization means that only one method is run at a time. Two different ASP worker threads cannot execute multiple methods on the shared component at the same time. This eliminates concurrency, especially on multi-processor computers. Worse, all components in the non-Agile application scope share one thread (host Sta), so the effects of serialization are even more significant. What do you do? Below are some general rules. If you write objects using 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. Instead of caching non-agile objects, you should create and release them on each page. Objects run directly on ASP worker threads, so they are not pooled OR serialized. If COM objects run on the IIS server and they are not initialized or deleted for a long time, the performance is acceptable. Note that single-threaded objects should not be used in this way. Be careful-VB can create a single-thread object! If you must use a single-threaded object (such as a Microsoft Excel spreadsheet) like this, do not expect high throughput. When ADO is marked as a free thread, the ADO record set can be safely cached. To mark ADO as a free thread and use the makfre15.bat file, the file is usually cached securely. To mark ADO as a free thread and use the makfre15.bat file, it is usually located in the directory // program files/common/system/ADO.
Warning if you use Microsoft Access as a database, do not mark ADO as a free thread. The ADO record set must also be disconnected. In general, if you cannot control the ADO configuration in the site, it is best not to cache the record set. Dictionary components are agile objects. Lookuptable loads its data from the data file, which can be used for the data and configuration information of the combo box. The pagecache object in duwa mish books provides dictionary syntax, and caprock dictionary can also. These objects or their derived objects can form the basis of an effective Cache Policy. Note that the scripting. dictionary object is not agile and 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 Object and used on all pages, all pages compete for this connection. If the connection object is stored in an ASP Session object, a database connection is created for each user. This will eliminate the advantages of the connection pool and put unnecessary pressure on web servers and databases. You can create and delete ADO objects on each ASP page using ADO without caching database connections. This is very effective because IIS is embedded with a database connection pool. More accurately, IIS automatically enables oledb and ODBC connection pools. This ensures that creating and deleting connections on each page is valid. Because the connected record set stores a reference to the database connection, you should not cache the connected record set in the application or session object. However, you can safely cache disconnected Record Sets without storing them as references to their data connections.
Tip 6: reasonably use session objects
Websites that require hundreds of pages or tens of thousands of users to access at the same time in one second, this technique is even more important for sites that must be horizontally scaled (that is, those that use multiple servers to handle load or implement fault tolerance. For small websites, such as Intranet sites, the system overhead will inevitably increase to realize the convenience brought by the session. In short, ASP automatically creates a session for each user accessing the web server. Each session requires about 10 KB of memory overhead (most importantly, data is stored in the Session), which slows down all requests. The session remains valid until the configured timeout period (usually 20 minutes) ends. The biggest problem with session is not performance, but scalability. A session cannot span several Web servers. Once a session is created on one server, its data remains there. This means that if you use session in a web server group, you must design a policy to always send each user request to the server where the user session is located. This is called "sticking" the user to the web server. If the Web server crashes, "stuck" users will lose their session status because the session is not stuck to the disk. Policies for implementing sticky sessions include hardware and software solutions. Solutions such as network load balancing in Windows 2000 Advanced Server and Cisco's local ctor can achieve sticky sessions at the cost of a certain degree of scalability. These solutions are incomplete. We do not recommend that you deploy your own software solutions at this time (we used to use ISAPI filters, URL conversion, and so on ). The application object does not span multiple servers. If you must share and update application data across the Web server group, you must use the backend database. However, read-only application data is still useful in the web server group. If you only want to increase the running time, read-only application data is still useful in the web server group. If you only need to increase the running time (to handle failover and server maintenance), you must deploy at least two Web servers for most critical task sites. Therefore, when designing key task applications, you must implement "Sticky sessions", or simply avoid using sessions, and any other State management technology that stores user statuses on a single web server. If you do not use sessions, you must disable them. You can use Internet Services Manager to perform this operation on applications. If you decide to use sessions, you can use some methods to mitigate their impact on performance. You can move unnecessary session content (such as the help screen and visitor area) to another ASP application that closes the session. You can prompt ASP page by page. You no longer need the session object on the page. Use the following command on the top of the ASP page: There is a good reason to use this command, these sessions have an interesting question about the framework set. ASP ensures that only one session request is executed at any time. This ensures that if the browser requests multiple pages for a user and only one ASP Request contacts the session at a time, the multithreading problem occurs when the session object is accessed. Unfortunately, all pages in a framework set will be displayed in serial mode, one by one, rather than simultaneously. You may have to wait a long time to see all the frameworks. The implication of this story: if some framework set pages do not rely on sessions, you must use the enablesessionstate = false command to tell ASP.
There are many methods to manage the session status, which can replace the use of session objects. For a small number of States (less than 4 kb), we generally recommend using cookies, querystring variables, and implicit variables.
Tip 7: encapsulate code in a COM Object
If you have many vbscripts or jscripts, you can often move the code to the compiled COM object to improve performance. The compiled code usually runs faster than the interpreted code. The compiled COM object can access other COM objects through "Early binding". "Early binding" is a more effective method for calling COM objects than the "late binding" used by the script. Encapsulating code in a COM object has some advantages (in addition to performance ):
The COM object is conducive to separating the representation logic from the business logic.
The COM object can be used repeatedly.
Many developers found that code written in VB, C ++, or Visual J ++ is easier to debug than ASP.
COM objects also have disadvantages, including the initial development time and different programming skills. Note that encapsulating a small amount of ASP may cause performance degradation without performance improvement. This usually occurs when a small amount of ASP code is encapsulated into a COM object. In this case, the system overhead for creating and calling COM objects exceeds the advantages of compiled code. It should be tested repeatedly to determine the combination of ASP scripts and COM Object code to produce the best performance. Note: Compared with Microsoft Windows NT & reg; 4.0/IIS 4.0, Windows 2000/IIS 5.0 greatly improves script and ADO performance. Therefore, with the launch of IIS 5.0, the performance advantage of compiling code is lower than that of ASP code. If you deploy COM components, it is especially important to test them at load. In fact, all ASP applications should be tested for load.
Tip 8: Get resources later and release resources earlier
Here is a tip for your reference. In general, it is better to get resources later and release resources earlier. This applies to COM objects, file handles, and other resources. This optimization method is mainly used for ADO connection and record set. When you use the record set, for example, after displaying a table and its data, you should release it immediately instead of waiting until the page ends. It is best to set the VBScript variable to nothing. Do not leave the record set out of the scope. In addition, to release any related command or connection objects (do not forget to call close () before setting the record set or connection to = nothing ()). This will shorten the time required for the database to prepare resources for you and release the connection from the database to the connection pool as soon as possible.

Tip 9: Out-of-process execution processes exchange performance for Reliability
Both ASP and MTS/COM + have configuration options to ensure both reliability and performance. When establishing and deploying applications, you should know how to take into account the performance of both. ASP options allow you to configure ASP applications to run in one of the three methods. In IIS 5.0, the "isolation level" term is introduced to describe these options. The three isolation levels are low, intermediate, and advanced:
Low-level isolation: This is supported in all versions of IIS and is the fastest. It runs ASP in inetinfo.exe, and inetinfo.exe is the main IIS process. If the ASP application crashes, IIS also crashes. (To restart IIS in IIS 4.0, the Web site administrator should use tools such as inetmon to monitor the site. If the server fails, batch files should be enabled to restart the server. IIS 5.0 introduces a reliable restart method, which can automatically restart the faulty server .)
Intermediate isolation: IIS 5.0 introduces this new level, which is called the out-of-process level because ASP runs outside the IIS process. In intermediate isolation, all ASP applications configured to run as intermediate isolation share a process space. This reduces the number of processes required to run ASP applications outside of multiple processes on a server. Intermediate isolation is the default isolation level in IIS 5.0.
Advanced isolation: this level is 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 next ASP request will automatically restart the ASP application. In advanced isolation, each ASP application that is configured to run as an advanced isolation runs in its own process space. This protects ASP applications from mutual interference. The disadvantage is that each ASP application requires a separate process. When many applications must be run on a server, the system overhead will be greatly increased.
Which of the following is the best? In IIS 4.0, the out-of-process route significantly reduces performance. In IIS 5.0, many improvements have been made to minimize the overhead of running ASP applications outside the process. In fact, in most tests, ASP out-of-process applications in IIS 5.0 run faster than in-process applications in IIS 4.0. In any case, the process (low isolation level) performance is the best on both platforms. However, if the yield rate is relatively low or the maximum throughput is low, the advantage of low isolation level is not obvious. Therefore, when each web server requires hundreds or thousands of pages per second, it is necessary to set a low isolation level. As usual, multiple configurations should be tested to determine which compromise plan to adopt.
Note that when you run an ASP out-of-process application (intermediate or advanced isolation), they run in MTS in NT4 and in COM + in Windows 2000. That is, in NT4, they run in mtx.exe, while in Windows 2000, they run in dllhost.exe. You can see that these processes are running in task manager. You can also see how IIS configures the MTS Package or COM + application route for ASP applications outside the process. You can also see how IIS configures MTS packages or COM + applications for ASP applications outside the process.
Com Option
COM components also have three configuration options, although not exactly the same as ASP options. COM components can be "unconfigured", configured as Library applications, or configured as server applications. "Not Configured" means that the component is not registered with COM +. Components will run in the process space of the calling program, that is, they are "in-process ". Library applications are in-process, but use COM + services, including security, transaction, and context support. Server applications are configured to run in their own process space.
You can see that unconfigured components have some advantages over Library applications. Database applications have higher performance advantages than server applications. This is because the library application runs in the same process as ASP, and the server application runs in their own process. Inter-process calls have higher overhead than intra-process calls. In addition, when data such as record set is transmitted between processes, all data must be copied between two processes.
Trap! When using a COM server application, if you pass objects between ASP and COM, make sure that the objects are executed by value collection or mbv. The objects that execute mbv copy them from one process to another. This is better than the following method. When this method is used, the object is still in the process of the Creator, and another process repeatedly calls the creation process to use this object. The cut-off ADO record set will "collect by value", and the connected record set will not. Scripting. dictionary does not execute mbv and does not pass between processes.
Finally, VB programmers should note that mbv is not obtained by passing the byval parameter. Mbv is executed by the original component author. What should I do?
If we recommend a reasonable configuration that combines performance and reliability, the configuration should be as follows:
In IIS 4.0, ASP is used for low isolation and MTS server packages.
On IIS 5.0, ASP is used for isolation and COM + Library applications.
These are very general principles,HostA service company generally runs ASP at the middle or high isolation level, while a single-purpose Web server can run at the lower isolation level. Measure the pros and cons and decide which configuration meets your needs.
Tip 10: use explicit options
Option explicit should be used in the. asp file. This command is placed at the top of the. asp file, which forces developers to declare all variables to be used. Many Programmers think this method is very helpful for debugging applications, because it avoids the possibility of key-error variable names and mistaken creation of new variables (for example, using myxmlstring =) the error is written as myxlmstring = ....
More importantly, declared variables are faster than undeclared variables. Therefore, the script references the variable by name every time it uses an undeclared variable during running. On the other hand, declared variables are sequential, either at compile time or run time. Later, all declared variables are referenced in this order. Because option explicit forces variable declaration, it ensures that all variables are declared, so the access speed is fast.
Tip 11: use local variables in subroutines and functions
Local variables are those declared in subroutines and functions. In a function or subroutine, local variable access is faster than global variable access. The use of local variables also makes the code clearer. Therefore, use local variables whenever possible.
Tip 12: Copy frequently used data to script variables
When accessing the COM Object in ASP, copy frequently used object data to the script variable. In this way, the com method call can be reduced because the overhead of COM method call is relatively large compared with the Access Script variable. When accessing collection and dictionary objects, this technology also reduces the overhead of searching.
Generally, if you want to access object data more than once, you should put the data in the script variable. The main objective of this optimization is the request variable (Form and querystring variables ). For example, your site can pass a querystring variable named userid. Assume that this userid is referenced for 12 times on a specific page. You do not need to call request (? Userid ?) The USERID is assigned at the top of the ASP page 12 times. You do not need to call request (? Userid ?) The USERID is assigned to a variable at the top of the ASP page 12 times. Then use the variable from start to end on the page. In this way, 11 com method calls are saved. In fact, the overhead for accessing com properties or methods is not that large.
Tip 13: avoid re-determining the array dimension
Avoid redim arrays whenever possible. In terms of performance, if the physical memory size of the computer is limited, it is best to set the initial dimension of the array to its most unfavorable condition-or set the dimension to its optimal condition, then re-determine the dimension as needed. This does not mean that if you know that you do not need memory, you can allocate a few megabytes of memory.
The following code shows you how dim and redim are used improperly.
<%
Dim myarray ()
Redim myarray (2)
Myarray (0) =? Hello?
Myarray (1) =? Good-bye?
Myarray (2) =? Farewell?
...
'Some other code where you end up needing more space happens, then...
Redim preserve myarray (5)
Myarray (3) =? More stuff?
Myarray (4) =? Even more stuff?
Myarray (5) =? Yet more stuff?
Myarray (5) =? Yet more stuff?
%>
It is better to correct the initial size dim of the array at the beginning (in this example, It is 5) to make it much better than the redim array. You may waste some memory (if you do not use all the elements), but the advantage is that the speed becomes faster.
Tip 14: Use response Buffering
You can enable "response Buffering" to buffer the entire page to be output. In this way, the amount of data written to the browser is minimized to improve the overall performance. Each write operation generates a large amount of system overhead (in IIS and the amount of data sent over the network). Therefore, the fewer write operations, the better. Because it is slow to start and uses the nagling algorithm (to reduce network congestion ), TCP/IP is much more efficient when sending large data blocks than when many small data blocks must be sent.
There are two ways to enable response buffering.
First, you can use Internet Services Manager to enable response buffering for the entire application. We recommend that you use this method. in IIS 4.0 and IIS 5.0, the new ASP application enables response buffering by default.
Second, you can add the following code lines near the top of each ASP page to enable response buffering:
<% Response. Buffer = 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 before any cookies are set using the response. Cookies set ). In general, it is best to enable response buffering for the entire application. In this way, you do not have to write the above Code lines at the top of each page.
Response. Flush
There is a common complaint about response buffering, that is, users feel that the response speed of ASP pages is slow (even if the overall response time is improved), because they have to wait until the entire page is generated, then they can see things. Because they have to wait until the entire page is generated before they can see things. For pages with long running time, you can set response. buffer to false to disable response buffering. However, a better strategy is to use the response. Flush method. This method sends all HTML converted by ASP to the browser. For example, ASP can call response after converting the first 1,000 rows of a table with 100 rows. flush, force the conversion result to the browser so that the user can see the first 100 rows before the remaining rows are ready. This technology can perfectly combine the Response Buffer with the browser's gradual display of data. (Note that in the example of the above 1,000 rows table, many browsers do not show the table before they see the close </table> mark. Check whether your target browser supports this function. To avoid this situation, the table is divided into multiple tables with fewer rows and response. Flush is called after each table. Earlier versions of Internet Explorer show the table before the table is completely downloaded. If you specify the table width, the display speed will be extremely fast, this avoids forcing Internet Explorer to calculate the column width by measuring the content width of each cell .) Another common complaint about response buffering is that when a very large page is generated, it will occupy a lot of server memory. Regardless of the method for generating large pages, this problem can also be solved by clever use of response. Flush.
Tip 15: batch processing embedded scripts and response. Write statements
VBScript syntax <% = expression %> writes the value of "expression" to the ASP output stream. If the response buffer is not enabled, every statement in the buffer writes data to the browser over the network with many small packets. This is slow. In addition, interspersed execution of a small amount of scripts and HTML will lead to switching between the script engine and HTML, thus reducing performance. Therefore, use the following technique: Use response. Write to call instead of bundled nested expressions. This technique is especially effective when response buffering is disabled. It is best to enable response buffering and check whether the batchcompute response. Write helps improve performance.
Tip 16: If the page takes a long time to complete, use response. isclientconnected before execution.
If users are impatient, they may discard the ASP page before you start to execute their requests. If they click Refresh or move to another page on the server, there is a new request waiting at the end of the ASP Request queue, and there is a disconnect request in the middle of the queue. When the server load is very high (so the Request queue will be very long and the response time will also get longer), this situation will often occur, which can only make the situation worse. If the user no longer connects, it makes no sense to execute ASP pages (especially slow and large ASP pages ).
. You can use the response. isclientconnected attribute to check this situation. If false is returned, call response. End and discard the rest of the page. In fact, IIS 5.0 has compiled this practice into a program-whenever ASP is about to execute a new request, it will check how long the request has been waiting in the queue. If you have waited there for more than 3 seconds, ASP will check whether the client is still in the connection status. If no connection has been there for more than 3 seconds, ASP checks whether the client is still connected. If no connection is established, the request is terminated immediately. You can use the aspqueueconnectiontesttime setting in the configuration database to change the timeout value from 3 seconds to another value. If the page takes a long time to complete, you can also check response. isclientconnected from time to time. When response buffering is enabled, it is best to execute response. Flush from time to let the user know what is going on.
Note: on IIS 4.0, response. Write is executed first, otherwise response. isclientconnected will not work properly. If buffering is enabled, you must also execute response. Flush. -Response. isclientconnected works normally. Response. isclientconnected has some overhead, so it takes at least (for example) 500 milliseconds for an operation (if you want to maintain the throughput of dozens of pages per second, this is a long time).
Experience shows that you should not call it every time you repeatedly execute a tight loop. For example, it may be appropriate to show many rows in the table-call at every 20 or 50 rows.
Tip 17: Use <Object> to mark the example object
If you want to reference objects that are not in all code paths (especially objects in the server or Application Scope), use global. the <object runat = server id = objname> flag in ASA declares them without using server. createobject method. Server. Createobject can create an object immediately. If you no longer use this object, you will waste resources. The <Object ID = objname> flag declares the objname. However, no objname is created before its method or attribute is used for the first time. This is another example of inert computing.
Tip 18: Use typelib statements for ADO and other components
When using ADO, developers often add adovbs.txt to access various constants of ADO. This file must be included on every page where constants are to be used. This constant file is quite large, giving Compilation Time and script skills for each ASP page 18: Using typelib to declare the size of this file for ADO and other components adds a lot of system overhead. IIS 5.0 introduces the function of binding to the component type library. This allows you to reference the type library once and use it on each ASP page. Each page does not incur the overhead of compiling constant files, and component developers do not have to create VBScript # _ include files for use on ASP. To access ADO typelib, place the following statement in global. Asa.
<! -- Metadata name =? Microsoft ActiveX Data Objects 2.5 library?
Type =? Typelib? UUID =? {00000205-0000-0010-8000-00aa006d2ea4 }? -->
Or
<! -- Metadata type =? Typelib?
File =? C:/program files/common files/system/ADO/msado15.dll? -->