28 rules on ASP performance optimization proposed by Microsoft II

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. To disconnect a record set, perform the following two steps:

Set rs = server. Createobject (? ADODB. recordset ?)
Rs. cursorlocation = aduseclient 'step 1

'Populate the recordset with data
Rs. Open strquery, strprov

'Now disconnect the recordset from the data provider and Data Source
Rs. activeconnection = nothing 'step 2

For more information about the connection pool, you can find it in ADO and SQL Server references.

Tip 6: reasonably use session objects

Now that we have discussed the advantages of caching in application and session, we will discuss how to avoid using session objects. As discussed below, session has several disadvantages when used together with busy sites. "Busy" means websites that require hundreds of pages or thousands of users at the same time in one second. This technique is even more important for sites that must be horizontally scaled-those that use multiple servers to handle loads or implement fault tolerance. For a small site, such as an Intranet site, if you want to implement the side of the session, the system overhead will inevitably increase.

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. The term "Sticky session" is derived from this. 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 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, in the design of key task applicationsProgramYou 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 (see the ISM documentation ). 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, and use the following commands at the top of the ASP page:

<% @ Enablesessionstate = false %>

A good reason for using this command is that these sessions have an interesting problem in 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. Backend databases are the best choice for larger data volumes, such as shopping carts. About the Status Management Technology in the web server groupArticleA lot. For more information, see session status reference.

Tip 7: SetCodeEncapsulated in 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.

For a detailed discussion of the advantages and disadvantages of using COM in ASP, see ASP Component guidelines and programming distributed applications with and Microsoft Visual Basic 6.0. 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
You can configure an ASP application 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, known as 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 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, use the ASP moderate isolation level and the COM + Library application.
these are general principles. Generally, host service companies run ASP at the medium or high isolation level, while single-purpose Web servers can run at a low isolation level. Measure the pros and cons and decide which configuration meets your needs.