Anyone who has written a slightly larger ASP knows that Session is really useful. It can be used to record user-owned data variables, which is both safe and convenient. But do you really know how Session works? Perhaps after you understand, you will never dare to use this love-hate object again. Although the method of changing to alternatives is a bit troublesome, after long-term considerations, I have to do so.
First, let’s talk about the benefits of Session, which can be used to record data variables privately owned by the client and will not disappear within the time range. This is really an important function, especially those that must be used by systems with members. For example, the member's login account, time, status, and many real-time data recorded (such as the shopping system records the products in the user's shopping basket), this information is the private needs of each user, and usually the developer uses it. Session Record processing.
However, the Session in ASP is composed of cookies, and the server transmits all the information recorded in the Session to the user's browser in the form of cookies. Usually, browsers will save these cookies. Whenever the user clicks on the link and connects it to the server again, the browser will pass these cookies back to the server for processing. This is the operating principle of Session. When the amount of data is larger, it must be transmitted and collected. It not only consumes the bandwidth of the line, but also reduces the performance, because the server must spend more resources on online processing and reconfigure memory, etc. Initial action. Now you may think, "I have to use this function, so I have to sacrifice a little." However, this article talks about Session. On the one hand, it is to teach everyone to use less; on the other hand, of course there are alternatives. Then they come on stage, which is also within Global.asa. Application object.
Application is also a good at recording and processing temporary data. Its abilities and usage in all aspects are the same as Session, but in comparison, the data it records is public, that is, a variable space that any user can share. Application is not like Session, which does not pass the data to the user and wait for the next time to read it back online. It is recorded directly on the memory on the Server, and the performance is much faster than Session.
Since Application objects are public, the first thing that must be done is to plan a common area for each user, so that each user has his own area to record data to achieve the purpose of a simulation session. There are two ways to do it now:
1. Initialize 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 powered on, it also saves the trouble of having to allocate every time the user is online. However, there is a limitation. Using this method must limit the maximum number of people. Since it is initialized as soon as it is activated, we can only estimate the establishment 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 applications. It adopts a dynamic allocation method. Only when the user comes online to the Server for the first time, the resource will be allocated to this user. The purpose of these two simulated Session solutions is to reduce the consumption of Session resources, but after all, it is still irreplaceable. We still need to use a little Session, which can at least reduce a lot of burden on the Server.
■First plan
First we start the implementation of the first solution. Since it is to initialize Application when activated, we must of course start from Global.asa:
Initialization has been completed, but how to use it? We just need to change the information stored in the Session, such as account and login time, into the Application object we have created, where the user logs in:
| 'Looking 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 the used state Application(User_Status_ & i) = 1 'Put into variable data Application(User_Account_ & i) = Account Application(User_Logtime_ & i) = Now() 'Unlocked Application.Unlock Exit For End If Next |
To obtain the user's relevant variable data, it is like the following:
| Response.Write(Application(User_Account_ & Session(Index)) |
You may find that you don't mean not to use Session? Then why does Session exist in the original code above? As mentioned earlier, this alternative cannot completely replace Session. The browser is not always online with the Server. It will be disconnected after reading the page. So how do we know if the same person is online next time? At this time, we have to rely on Session. We give the user a set of real-time numbers. This number is the number of the user in the variable space on the Application. You can imagine that there are many safes in the bank. You have a key, and the key is There are numbers on it, and the number on the key allows the trainer to lead you to your own safe. This method has some improvements, but it is enough for small applications.
■Second Plan
Regarding the previous solution, you may also think that our customized number uses Session to record. Speaking of numbering, the Session object provides a "SessionID" method. That's right, no matter whether we want to use it or not, Server will automatically help each user assign a number, and this number will not be repeated. As for this number, it is obtained with Session.SessionID. This numbering is an action that Session will definitely do, so we can use it to replace the numbering program we write ourselves, which saves another effort and even has greater expansion. But basically, the first solution above is still useful, such as chat rooms that limit the number of people and other small applications. The next second alternative is for larger systems.
If a website with hundreds, thousands or even tens of thousands of people on a website every second, it will definitely not work if it uses the previous solution. Suppose you set the upper limit of 10,000 people, once Server is activated, it will help you cut out 10,000 areas to prepare for 10,000 users. If there are 5 variables in a region, one variable accounts for 32 bytes (Byte), and 10,000 It only accounts for more than 320,000 K (320MB). Once the Server is activated, it will stuff so much garbage into memory. The performance will definitely be reduced a lot before it even goes to the battlefield. And even though these numbers are very few, I think that 512MB of your own will be enough. , the above number is assumed to be a minimum number, plus how much additional resources the Server will use when configuring memory is unknown, so it will only be more and not lower. Therefore, the solution is to dynamically configure the user variable space, and cut a piece of area when a user is online with the Server, so there is no need to configure huge memory in advance.
The second solution is relatively simple to do. Please throw away all the things in the first solution. We don’t need to move to Global.asa, we only need to change the user login and other useful places:
| 'Lock ApplicationApplication.Lock' put variable data Application(User_Account_ & Session.SessionID) = Account Application(User_Logtime_ & Session.SessionID) = Now() 'Unlock Unlock Application.Unlock |
To obtain the user's relevant variable data, it is like the following:
| Response.Write(Application(User_Account_ & Session.SessionID)) |
In the past, I read many books that said Session was very hard to eat resources, so try not to use them, but I still have to use them when they have to, and the books did not teach a more appropriate solution. Now when you understand how to replace Session, make good use of it! Perhaps the efficiency problems that are always troubled can be improved a lot!