How to Enhance ASP program performance (2)

How to Enhance ASP program performance (2)
2000-08-11 · Compiling: Gan Ganping · Yesky
Tip 6: Use session objects wisely
Sessions have several drawbacks when they are used on a busy site. Busy means: Hundreds of pages are requested per second on the site, or thousands of users are being accessed at the same time. This technique is important for sites that require horizontal scaling: They use multiple servers to complete data loading or handle large amounts of fault tolerance. For small sites, such as Intranet intranet,session, is well worth advocating.
Again, the ASP automatically creates a session for each user who clicks on the Web server for the first time, with approximately 10KB of memory each, with a lifetime of 20 minutes by default.
The biggest problem with session is not performance, but extensibility, the session cannot span multiple Web servers, and once the session is created on a server, its data resides there. This means that if you use session on the Web, you will need to design a policy for each user who accesses the sessions server directly. This is to "glue" the user on the Web server, the term "sticky sessions" comes from this. If the Web server encounters a barrier, the "stuck" user loses their session status because the sessions are not kept on disk.
Strategies for performing sticky sessions include hardware and software solutions, such as the network Load balancing in Windows2000 Advanced servers, and Cisco's local Director, but in return for these sacrifices some extensibility.
Application objects also cannot span servers. If you need to share and update application data in a Web farm, you need to use a background database. However, read-only application data is still useful in the Web farm.
Many sites that are demanding for a task have at least 2 Web servers set up, so when designing a strict task application, you need to perform "sticky sessions" or simply avoid using the session. You can also take other management techniques that save the user's state to a stand-alone Web server.
If you do not use session, be sure to turn them off, which can be done through Internet Services Manager. If you decide to use session, there are several ways to minimize their impact.
You can move content that does not require a session (such as Help screen, visitor area, and so on) to a stand-alone ASP application that closes the session. On the underlying page, you can give the ASP an indication that it does not need to use session. Add the following code directly to the head of the ASP page:

<% @EnableSessionState =false%>
A good explanation for using this indicator is that the session in the frame structure creates an interesting problem. ASP ensures that only one request from the session is executed at a time, which ensures that if the browser requests multiple pages for a single user, only one ASP request can accept the session at that time, thus avoiding multithreading problems when accessing the Session object. Unfortunately, all the pages in the frame structure will appear in sequential order, one by one, not at the same time, so the user has to wait a long time to see the entire frame. The rule is: if a certain frame page does not use session, be sure to tell the ASP to directly use @enablesessionstate=false.