Asp. NET through distributed session to improve performance _ practical skills

If we are using session, then building high-performance scalable asp.net Web sites must address the architecture of distributed sessions because of the rapid performance bottlenecks in a single server, which is also called synchronization. Microsoft has its own distributed session solution, that is sessionstateserver, we can refer to:

asp.net session state Partitioning
Http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx

asp.net load balancing and asp.net state server
http://blog.maartenballiauw.be/post/2007/11/aspnet-load-balancing-and-aspnet-state-server-(aspnet_state). aspx

But this article is to change a scheme, that is using memcached to reach the distributed session architecture. Memcached as a distributed caching server has been widely used in the construction of the website.

One: The mechanism of the session

The session is for the user and we can also understand that it is for the browser. When the browser first accesses the ASP.net page (the page does not turn off the session feature), it sends the following HTTP headers to the client:

When the browser receives the HTTP header above, it will save the unique SessionID in its own cookie (as long as the cookie is not disabled, this article does not discuss the case for disabling cookies, refer to Ben Boven http://www.cnblogs.com/ Fish-li/archive/2011/07/31/2123191.html, wrote very nice). When the browser requests the server again for access, it adds the following identifier to the request HTTP header, and we can see that the SessionID is the SessionID above:

This is the mechanism by which browsers and servers are used to ensure user sessions.

If the client browser disables cookies, we will find that each time the browser Set-cookie is different, the cookie ID will never appear in the Send request header. At this time, we will find the session is invalid (of course, in order to prevent this situation, Microsoft allows us to set cookieless= "true" in sessionstate, passing SessionID by URL).

Two: Memcached Providers

I use the memcached client is memcached Providers, after downloading, you will find memcached Providers has provided the support function to the distributed session. If you are not using memcached Providers, please refer to this article memcached Tip 1: Use memcached Providers. The example provided by Memcached providers is that the session is stored directly in the database, and we can configure the session support to be stored in the distributed session memory, that is, the dbtype below is modified from SQL to none. ：

Using the distributed session provided by memcached providers is nothing special, because the Sessionstateprovider type provided by memcached providers is implemented in asp.net Sessionstatestoreproviderbase this abstract class, we can see that the processing class for the session specified in the configuration file is Sessionstateprovider, so the ASP. NET after receiving the request of the client, will consciously drop using Sessionstateprovider to handle all the sessions, it is this class that completes the session reading and storing in memcached (if SQL is set, is stored synchronously to the SQL Server database.

Session settings and reads are no different from the tradition, read:

      session["sname2"] = "SLUMINJXXI";
      Session.Timeout = 2;

Take:

      Response.Write (session["sname2"]);

Three: Why do you want to configure SQL

The disadvantage of the traditional session is that it exists only when the DBTYPE is configured with none. What happens when the memcached memory reaches the upper limit? memcached use the LRU elimination algorithm (the longest unused), where we do not need to examine the algorithm in the memcached is what kind of a mechanism, we just need to know, in memory tense, even if the session time has not arrived, Memcached could have killed it, too. Therefore, the insurance practice is, under the memcached, plus the persistence of SQL Server preservation. If the cache hits, take the cache directly, and if the cache is dead, then confirm it again in the database. Of course, this can lead to some performance loss, but it's a safer approach.

The download file provided by Memcached providers provides some scripts for initializing the session, which, when executed correctly, generates a table tblsessions as follows, and several stored procedures:

Tblsessions Save is a separate session, as follows:

Four: A bug in Memcached providers

There is a bug in the current memcached Providers (version 1.2) about Sessionstateprovider (29520-trunk) (I have submitted to CodePlex that their next version should be able to be corrected). If we test the session expiration time, we find that once refreshed, it is always 20 minutes (that is, the default). This is due to the fact that in releaseitemexclusive this overloaded method, which frees up locks on items in the session data store, no expiration time is added to the re-storage of sessions, as follows:

Comment Out is memcached providers provided the source code, and the correct should be the last one I have fixed. With the corrected DLL, everything is perfect.

Five: Scalable problem with database storage session

With a further increase in the number of visits (of course, to this extent, the site is very successful, most of the site does not need to consider this step), even if we use the memcached for caching, using a single SQL Server storage session still brings performance problems, In this case, we can use a horizontal partitioning framework for the design of the database, which is to store the session in a different database based on an algorithm that can be SessionID, or user name, and so on. This time, if we still use memcached Providers, then we must further modify the source code, from the original support of a single SQL Server servers, programming support for multiple servers. Of course, if you do not like SQL Server, you can also modify to support MySQL, MongoDB, any custom key-value framework, and so on, this is something, for the moment not table.