Programming | skill | Skill control Session Strictly
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%>
Caching frequently used data on a Web server
Typically, an ASP page retrieves data from a background store and then forms the result in Hypertext Markup Language (HTML). Retrieving data from memory is much faster than from a background storage device, regardless of the speed of the database. Reading data from your local hard disk is usually very fast. Therefore, improving performance can be achieved by caching the data on the server, either by caching the data in memory or by the local hard drive.
Caching is the classic "space for Time" compromise. If the cache is properly cached, you can see significant performance improvements. In order for caching to be effective, it is necessary to ensure that cached data is often reused and computationally cumbersome. Caching a cache full of stale data is a waste of memory.
Data that is infrequently changed is a good object for caching because it does not need to be considered at any time when the data is updated for synchronization operations. combo boxes, reference tables, DHTML code, extended Markup language strings, menus, and site configuration variables (including the data source name, Internet Protocol address IP, and Web path) are good caching objects. Note: You want to cache the data expression instead of the data itself. If an ASP page changes frequently and is laborious to cache (such as the entire product catalog), consider generating HTML instead of describing it every time a request occurs.
Caching frequently used data in a application or Session object
The application and session objects in ASP are convenient containers for caching data in memory. You can assign data to application and session objects, which will remain in memory for the duration of the HTTP call. The data in the session is serviced for each user, and the data in the application is shared by all users.
When do I need to mount data in application and session? Typically, when the application starts or the session begins, the data is loaded. To load the data at this point, add the appropriate code to the application OnStart () or Session OnStart (). These functions are in the file Global.asa and are added if they do not exist. You can also call in when the data is needed for the first time, add code to the ASP page, check whether the data exists, and if it is not found, transfer it. Here's an example of what it means to be a classical that is called the "lazy evalution": until it is needed, to compute it.
Copy frequently used data into script variables
When accessing COM objects in ASP, you should copy frequently used object data into script variables, thus reducing method calls to COM objects. These calls are more time-consuming and laborious than accessing script variables. Using this technique also reduces expensive lookup operations when accessing collection and Dictionary objects.
In general, if you want to access object data more than once, you should put the data into a script variable, which is mainly the request variable (form and query string variable). For example, a site is passing a query string variable called UserID, assuming that it will be referenced 12 times on a particular page, so you do not need to invoke request ("UserID") 12 times, as long as you assign UserID to a variable in the header of the ASP page, and then use it in the page, This saves the invocation of the COM method 11 times.
Use Server.Transfer whenever possible, instead of Response.Redirect
Response.Redirect tells the browser to request another different page, which is often used to guide the user to the login page or the error-handling page. Because redirection forces a new page request, the result is that the browser must cycle 2 times with the Web server, and the Web server must process an additional request. Server.Transfer performs page transfers on the same server, which avoids additional browser-web server data loops, creates good system performance, and has better response times for users. Of course, Server.Transfer only supports relative paths (that is, in-station use).
