Anyone who has written a slightly larger ASP knows that the Session object is really easy to use. It can be used to record the user's private data variables, which is both safe and convenient. But do you really know how Session works? Anyone who has written a slightly larger ASP knows that the Session object is really easy to use. It can be used to record the user's private data variables, which is both safe and convenient. But do you really know how Session works? Perhaps after understanding it, you will no longer dare to use this beloved and hated object. Although the alternative method is a little troublesome, after long-term consideration, it has to be done.
First, let's talk about the benefits of Session. It can be used to record the client's private data variables and will not disappear within the time range. This is really an important function, especially for systems with members that must be used. Such as the member's login account, time, status and many real-time data that should be recorded (such as the shopping system recording the items in the user's shopping basket). This information is privately needed by each user and is usually used by developers. Session record processing.
However, the Session in ASP is composed of Cookies, and the server transmits all the data recorded in the Session to the user's browser in the form of Cookies. Usually, general browsers will store these cookies. Whenever the user clicks on a link and connects to the server again, the browser will send these cookies back to the server for processing. This is the operating principle of Session. When the amount of data is larger, since it must be sent out and taken back, it not only eats up line bandwidth, but also reduces performance because the server must spend more resources on online processing and reconfiguring memory. Initial action. Now you may be thinking, "I have to use this function, so I have to sacrifice it." However, this article talks about Session. On the one hand, it teaches you to use it less; on the other hand, of course there are alternatives. The next thing that comes up is that it also belongs to Global.asa. Application object.
Application is also good at recording and processing temporary data. Its capabilities and usage are the same as Session in all aspects. However, in comparison, the data it records is public, that is, a variable space that can be shared by any user. Unlike Session, Application does not transfer data to the user and wait for the next connection to read it back. It is directly recorded in the memory on the Server. In comparison, the performance is much faster than Session.
Since the Application object is public, the first thing that must be done is to plan a common area for each user, so that each user can have his own area to record data, in order to achieve the purpose of simulating Session. There are two approaches now:
1. Initialize, create and allocate user memory space in advance when the Server is activated. Usually, although this approach occupies a lot of resources as soon as the Server is started, it also saves the trouble of having to allocate it every time the user is online in the future. But there is a limitation. This method must limit the maximum number of people. Since it is initialized as soon as it is activated, we can only estimate the creation of a certain amount of memory space, so this method is usually used in small programs such as chat rooms.
2. This method should be considered more appropriate for large-scale applications. It adopts a dynamic allocation method and starts allocating resources to the user when the user first connects to the server. The purpose of these two methods of simulating Session is to reduce the consumption of Session resources, but after all, they cannot be completely replaced. We still need to use a little bit of Session, which at least can reduce a lot of burden on the Server.
First option
First we start the implementation of the first solution. Since the Application is initialized during activation, of course we have to start from Global.asa:
The initialization has been completed, but how to use it? We only need to change the data originally stored using Session, such as account number and login time, into the Application object we created where the user logs in:
Copy the code code as follows:
'Look for unused space
For i = 1 To Application(ClientMax)
If Application(User_Status_ & i) = 0 Then
'User temporary number
Session(Index) = i
'locking
Application Application.Lock
'Set to used state
Application(User_Status_ & i) = 1 'Put variable data
Application(User_Account_ & i) = Account
Application(User_Logtime_ & i) = Now()
'Unlock
Application.Unlock
Exit For
End If
Next
To obtain user-related variable data, do the following:
Response.Write(Application(User_Account_ & Session(Index))
You may find that isn't it said not to use Session? Then why does Session still exist in the above source code? As mentioned before, this alternative cannot completely replace the Session. The browser is not always online with the Server. It will be disconnected after reading the page. So how do we know that the same person is connected next time? At this time, we must rely on Session. We give the user a set of real-time numbers. This number is the number of the user's variable space on the Application. You can imagine that there are many safes in the bank. You have a key, and the key There is a number on it, and the number on the key allows the clerk to lead you to your own safe. There are still improvements to this method, but it is sufficient for small applications.
Second option
Regarding the previous solution, you may also think that our customized numbers are recorded using Session. Speaking of numbers, the Session object provides a "SessionID" method. That's right, regardless of whether we want to use it or not, the Server will automatically assign a number to each user, and this number will not be repeated. As for this number, it is obtained using Session.SessionID. This numbering is an action that Session will definitely do. We can use it to replace the numbering program we wrote ourselves, which also saves a lot of effort and even provides greater scalability. But basically, the first solution above still has its uses, such as small applications such as chat rooms that limit the number of people. The next alternative is for larger systems.
For websites with hundreds, thousands or even tens of thousands of visitors per second, the previous solution will definitely not work. Suppose you set the upper limit of the number of people to 10,000. Once activated, the Server will help you cut out 10,000 areas for 10,000 users. If there are 5 variables in an area, and one variable occupies 32 bytes, 10,000 It occupies more than 320000 K (320MB), Server As soon as it is activated, so much garbage is stuffed into the memory, and the performance is bound to be reduced a lot before it enters the battlefield; and don't look at these small numbers, and think that your 512 MB will be enough. The above numbers are assuming a minimum number, plus It is unknown how many additional resources the server will use when configuring memory, so it will only be more, not less. Therefore, the only solution is to dynamically configure the user variable space, and only cut out an area when a user is connected to the server. This way, there is no need to configure huge memory in advance.
The second option is relatively simple to implement. Please throw away everything in the first option. We don’t need to touch Global.asa. We only need to change the user login place and other useful places:
Copy the code code as follows:
'LockApplicationApplication.Lock 'Put variable data
Application(User_Account_ & Session.SessionID) = Account
Application(User_Logtime_ & Session.SessionID) = Now() 'Unlock Application.Unlock
To obtain user-related variable data, do the following:
Copy the code code as follows:
Response.Write(Application(User_Account_ & Session.SessionID))
In the past, I read many books that said that sessions are very resource-hungry, so try not to use them, but you still have to use them when you must, and the books didn't teach any more appropriate solutions. Now that you understand how to replace Session, take advantage of it! Perhaps the performance issues that have always troubled me can be improved a lot!