A wolf in sheep's clothing

The session wrote a slightly larger number of ASP people know that the session this object is really good, it can be used to record the user's private data variables, both safe and convenient. But do you really know how the session works? Perhaps you will never be too bold to use this loving and hateful object. While the alternative is a bit troublesome, it has to be done in the long term.

Let's start by talking about the good side of the session, which can be used to record the user's proprietary data variables and not disappear within the time range. This is really a very important function, especially for the members of the system that must be used. Like a member's login account, time, state and a lot of the instant information ﹝, such as the product ﹞ in the shopping system of the user's shopping basketball, which is the personal needs of each user, and usually the developers use the session recording.

However, the session in ASP is made up of cookies, and the server communicates all the session records to the user's browser in the form of cookies. Typically, a general browser will save these cookies, and each time the user points to the link, and then connect to the server again, the browser would send these cookies back to the server for processing. This is the principle of the session, when the amount of data is a bit larger, it has to be spread out and back, not only to eat the line bandwidth, but also to reduce performance, because the Server has to spend more resources to do the link and reconfigure the memory, and so on the initial motion. Now you might think, "I have to use this function, I have to make sacrifices," but this is one of the things that teaches us less; on the other hand, there is an alternative, and it is the Application object in the same global.asa.

Application is also a good player for the record, with all the capabilities and usage being the same as the session, which, by contrast, records information that is common, that is, any user can share the variable space. Application is not like the session, not the data to the user, and then the next link to read back, it is directly recorded on the Server memory, the relative efficiency of the session more quickly.

Since application objects are public, the first thing you have to do is to have a common area plan for each user, so that each user has its own area to record data for the purpose of the simulation session. There are two ways to do this: first, initialize and allocate the user memory space in advance of the Server, this is usually the case when a Server opens up a lot of resources, but it eliminates the hassle of having to do a distribution every time a user connects. But there is a limit to using this method to limit the maximum number of people, since it is initialized to initialize, we can only estimate the amount of memory space, so this method is often used in chat room this small program. Second, this method should be more appropriate for large applications, using the dynamic allocation method, when the user is first connected to the Server to start allocating resources to this user. The two simulation sessions are designed to reduce the cost of session resources, but after all, we still need to use a little bit of session, at least for the Server has been able to reduce a lot of burden.

First programme

First we start with the first scenario, and since we initiate the initialization of application, we are, of course, moving from Global.asa:




Initialization has been completed, but how to use it? As long as we are logged in by the user, we can change the data that was used in the session, such as account number, login time, into the Application object we built:

' Looking for unused space for i = 1 to Application ("Clientmax") If application ("User_status_" & i) = 0 Then ' User momentarily session ("Index") = I ' Lock application Application.Lock ' set to the Used state application ("User_status_" & i) = 1 ' into the variable data application ("User_account_" & i) = Account Application ("User_logtime_" & i) = Now () ' Unlock application.unlock Exit for End IfNext


Getting the user's relational data is like the following:

Response.Write (Application ("User_account_" & Session ("Index"))

You might find that you don't want to use the session? So why is there a session in the original code? As I said earlier, this alternative does not completely replace the session, the browser does not always and Server in the connection, read the page on the line, then how do we know the next link is still the same person? This time it has to be a session, we give the user a group of instant numbers, this is the number that the user has on the application, and you can imagine that there are a lot of insurance boxes in the bank, you have a keys spoon, and the keys key has the numbers, The number on the keys key allows the line member to lead you to your own insurance box. This approach has yet to be modified, but it has been used for small applications.

Second programme

As for the previous proposal, you may also think that our custom number uses a session to record, and that the "SessionID" method is provided by the sessions object. Yes, whether we want to use it or not, the Server will automatically help each user to encode the number, and this number will not be repeated, as this code is obtained with Session.SessionID. This number is an action that the session will do, and we can use it instead of our own coding program, and also save a lot of effort, even greater scalability. But basically, the first solution has its uses, such as small applications that limit the number of people in the chat room, and then the second alternative is the larger system.

There are hundreds of thousands of people on the Web site per second, and the previous plan must not work. Assuming you 10000 the upper limit, the Server's activation will help you cut out a realities area ready for a realities user, if there are 5 variables in one area, one variable occupies 32 bits (Byte) and 10,000 occupies 320000 K (320MB), the Server opens With so much rubbish in the memory, the effectiveness of the game will not go to the battlefield to reduce a lot; and don't look at these numbers very little, so that your own MB will be available, the number above is a dummy minimum, and the amount of information that Server uses to allocate memory is not known, so it will only be much less. So the solution is only to change the user's space, when there is a user and Server connection to cut out the area, so there is no need to configure the great memory.

The second scenario is simpler, please throw out the first solution and we don't need to move to Global.asa, just change the user login and other useful places:

' Lock Applicationapplication.lock ' into variable data application ("User_account_" & Session.SessionID) = Accountapplication (" User_logtime_ "& Session.SessionID" = Now () ' Unlock Application.UnLock


Getting the user's relational data is like the following:

Response.Write (Application ("User_account_" & Session.SessionID))


In the past, read a lot of books, write a session to eat resources to eat very fierce, although not to use, but must use the time still need to use, the book is not a more appropriate solution. Now when you know how to replace the session, take advantage of it! Or perhaps the problem of efficiency problems that can be disturbed so much!