ASP Skill Collection (Official Authority edition)-3

Skills Tip 6: Magical Session Objects
After affirming the benefits of caching in applications and Sessions, we recommend that you avoid using the Session object. As we'll talk about, Sessions has several drawbacks when it comes to busy sites. The so-called busy, usually refers to the site per second request hundreds of pages or at the same time thousands of users. This technique is more important for sites that must be scaled horizontally, that is, those that take advantage of multiple servers to accommodate load or perform fault tolerance. For smaller sites, such as intranet sites, the convenience of Sessions is also worthwhile compared to overhead.
To renovate, the ASP automatically creates a session for each user who accesses the WEB server. Each session has approximately a KB of memory overhead (the highest in any data stored in the session), and makes all requests slower. The session remains active until a configurable timeout (usually 20 minutes) is reached.
The biggest problem with session is not performance but scalability. A session cannot span a WEB server, and once it 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 request so that these requests are always directed to the server where the user's session is located. This is called "glue" the user to a WEB server. The term "sticky session" is derived from this. Because the session is not persisted to disk, the "stuck" user loses their Sessions status when the Web server crashes.
Strategies for implementing sticky sessions include hardware and software solutions. For example, the Network Load Balancing solution in Windows Advanced Server and Cisco's local pointer solution can implement sticky sessions at the expense of some scalability. These solutions are not perfect. We do not claim that you are now completely overturning your software solution (we have used ISAPI filters and URL straightening to check for scenarios).
Application objects also cannot span servers, and 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 realm.
If only to increase uptime (for handling failover and server maintenance), most sites that perform important tasks will need to deploy at least two Web servers. So, when designing an application that performs important tasks, you will need to implement a sticky session or simply avoid Sessions and any other state management technology that stores user state on a single WEB server.
If you are not currently using Sessions, be sure to turn them off. You can perform this operation for your application through Internet Services Manager (see the ISM documentation). If you decide to use Sessions, you can take a few ways to minimize the impact on performance.
You can move content that does not require Sessions, such as the help screen, visitor area, and so on, to a separate ASP application that is closed Sessions. You can prompt for ASP: You do not need a session object on a given page, and you use the following instructions at the top of the ASP page:
<% @EnableSessionState =false%>
A good reason to use this directive is that the session brings interesting problems to the frameset. The ASP guarantees that only one request from the session will be 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 a time, which avoids multithreading problems when accessing the Session object. Unfortunately, as a result, all pages in the frameset are plotted in a serialized way, one after the other, not at the same time. In this way, the user may have to wait a long time to get all the frame content. This means: If some frames pages do not trust session, be sure to use @EnableSessionState =false instructions to tell the ASP.
As an alternative to using the session object, there are many ways to manage session state. For small States (less than 4 KB), Cookies, querystring variables, and hidden forms are generally recommended. For a larger number of data, such as a shopping cart, using a back-end database is the most appropriate option. There is already a lot of information about state management techniques in the WEB server world. For more information, see Session state (in English).
　　
　　 Tip 7: Encapsulate code in a COM object
If you have a lot of VBScript or JScript, you can often improve their performance by moving the code to a compiled COM object. Compiled code usually runs faster than the interpreted code. Compiled COM objects can access other COM objects through early binding, and this method of invoking COM object methods is more efficient than "late binding" used by the script.
Encapsulating code in COM object species has the following benefits (beyond performance):
COM objects are a good way to separate the expression logic from the business logic.
COM object has code reuse enabled.
Many developers have found that code written in VB, C + +, or Visual J + + is easier to debug than ASP.
COM objects have some drawbacks, including initial development time and the need for different programming techniques. What you need to warn you about is that encapsulating the "less" amount of ASP can lead to performance degradation, not improvement. Typically, this occurs when a small amount of ASP code is encapsulated into a COM object. At this point, the overhead of creating and invoking COM objects exceeds the benefits of compiled code. It remains to be tested as to how ASP scripts and COM object code can be merged to produce the best performance. Note that Microsoft has dramatically improved script and ADO performance in Windows 2000/iis 5.0 compared to Windows NT (R) 4.0/iis 4.0. Thus, the performance advantages of compiled code for ASP code have been reduced with the introduction of IIS 5.0.
For more discussion on the pros and cons 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 important to test them for strength. In fact, all ASP applications should be tested for strength as a formal process.
　　
　　 Tip 8: Get resources later and release resources early
It's a little trick. Usually, it is best to get resources later and release resources early. These resources include COM objects, file handles, and other resources.
ADO connectivity and Recordset are the primary goals of this optimization. When you are finished using the recordset, that is, after you print a table with its data, release it immediately, instead of waiting for the end of the page. Setting your VBScript variable to nothing is the best practice. Do not leave the recordset simply out of scope. At the same time, any relevant Command or Connection object should be released. (Don't forget to call Close () on the recordset or "connect" before setting them to = Nothing.) This shortens the time span that the database must adjust for you and releases the database connection to the connection pool as quickly as possible.