Distributed session for ASP. NET performance optimization

If we are using session, we will build a high-performance and scalable ASP. net websites must solve the distributed session architecture, because the session processing capability of a single server will quickly experience performance bottlenecks, which are also called session synchronization. Microsoft has its own distributed session solution, sessionstateserver. For details, refer:

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
The http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state). aspx

However, this article is about another solution, that is, to use memcached to reach the distributed session architecture. Memcached has been widely used in website construction as a distributed cache server.

 

I. session mechanism

Session is intended for users, and we can also understand it as for browsers. When the browser first accesses the ASP. NET webpage (the session function is not disabled on the webpage), it will send the following HTTP header to the client:

After receiving the preceding HTTP header, the browser saves the unique sessionid in its own cookie (as long as the cookie is not disabled, this article does not discuss the case of disabling the cookie, for more information, see http://www.cnblogs.com/fish-li/archive/2011/07/31/2123191.html ). When the browser requests the server for access again, it will add the following identifier to the HTTP request header. We can see that this sessionid is the above sessionid:

This mechanism is used between the browser and the server to ensure the user's session.

If the cookie is disabled in the browser on the client, we will find that the set-cookie in the browser is different every time we refresh the browser, and the cookie ID will never appear in the sending request header. At this time, we will find that the session is invalid (of course, to prevent this situation, Microsoft allows us to set cookieless = "true" in sessionstate and use the URL to pass sessionid ).

Ii. memcached providers

The memcached client I use is memcached providers. After downloading the client, you will find that memcached providers has provided support for Distributed sessions. If you do not use memcached providers, refer to memcached tip 1: Use memcached providers. The example provided by memcached providers is to store sessions directly in the database. We can configure it to store sessions in the distributed session memory, that is, modify dbtype from SQL to none. :

The distributed session provided by memcached providers has nothing special, because the sessionstateprovider type provided by memcached providers implements ASP. the abstract class sessionstatestoreproviderbase in. net. We can see that the session processing class specified in the configuration file is sessionstateprovider. Therefore, Asp. net will consciously use sessionstateprovider to process all sessions after receiving requests from the client, which is exactly the same as this class, the session is read and stored in memcached. (If SQL is set, the session is stored in the sqlserver database ).

The setting and reading of sessions are no different from those of traditional systems. Read:

View sourceprint?

Session ["sname2"] = "sluminjxxi ";

Session. Timeout = 2;

Take:

View sourceprint?

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

 

Iii. Why should I configure SQL statements?

The disadvantage of traditional session exists when dbtype is set to none only. What if memcached's memory reaches the upper limit? Memcached uses LRU for eliminationAlgorithm(Not used for a long time). Here we don't need to go into details about the mechanism of this algorithm in memcached. We just need to know that when the memory is tight, even if the session time is not reached, memcached may also kill it. Therefore, it is safe to add persistent storage of sqlserver under memcached. If the cache hits, the cache will be taken directly. If the cache is dead, it will be confirmed again in the database. Of course, this will cause some performance loss, but it is a safer approach.

Some scripts for Session Initialization are provided in the download file provided by memcached providers. After the script is correctly executed, it will generate a table such as tblsessions and several stored procedures:

Tblsessions stores separate sessions as follows:

 

4. memcached providers bug

In the current memcached providers (version 1.2), there is a bug about sessionstateprovider (29520-trunk) (I have submitted it to codeplex and believe their next version should be corrected. If we test the session expiration time, we find that after a refresh, it will always be 20 minutes (that is, the default value ). This is because in the releaseitemexclusive overload method (this method is used to release the lock on the items in the session data storage area), there is no expiration time for session re-storage, as shown below:

The source code provided by memcached providers is commented out, and the correct one should be the one I corrected. With the corrected DLL, everything is complete.

 

V. scalability of sessions stored in databases

With the increase in access traffic (of course, to this extent, it indicates that the website is very successful and most websites do not need to consider this step), even if we use memcached as the cache, using a single SQL Server to store sessions still brings about performance problems. In this case, we can adopt a horizontal partition architecture for database design, that is, according to a certain algorithm (according to sessionid, or User Name) to store sessions in different databases. At this time, if we still use memcached providers, we must further modify the source code, which originally supported a single sqlserver server and programming to support multiple servers. Of course, if you do not like sqlserver, you can also change it to support MySQL, MongoDB, any custom key-value framework, and so on. If this is not the case, it will not be shown yet.

The first part of this series:

1: ASP. NET performance optimization-Build Custom File Cache

2: ASP. NET performance optimization to allow the browser to cache dynamic web pages

3: ASP. NET performance optimization to reduce requests

4: reverse proxy cache for ASP. NET performance optimization

5: local cache for ASP. NET performance optimization

This article is first published on agilesharp-entrepreneurial push Platform

If we are using session, we will build a high-performance and scalable ASP. net websites must solve the distributed session architecture, because the session processing capability of a single server will quickly experience performance bottlenecks, which are also called session synchronization. Microsoft has its own distributed session solution, sessionstateserver. For details, refer:

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
The http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state). aspx

However, this article is about another solution, that is, to use memcached to reach the distributed session architecture. Memcached has been widely used in website construction as a distributed cache server.

 

I. session mechanism

Session is intended for users, and we can also understand it as for browsers. When the browser first accesses the ASP. NET webpage (the session function is not disabled on the webpage), it will send the following HTTP header to the client:

After receiving the preceding HTTP header, the browser saves the unique sessionid in its own cookie (as long as the cookie is not disabled, this article does not discuss the case of disabling the cookie, for more information, see http://www.cnblogs.com/fish-li/archive/2011/07/31/2123191.html ). When the browser requests the server for access again, it will add the following identifier to the HTTP request header. We can see that this sessionid is the above sessionid:

This mechanism is used between the browser and the server to ensure the user's session.

If the cookie is disabled in the browser on the client, we will find that the set-cookie in the browser is different every time we refresh the browser, and the cookie ID will never appear in the sending request header. At this time, we will find that the session is invalid (of course, to prevent this situation, Microsoft allows us to set cookieless = "true" in sessionstate and use the URL to pass sessionid ).

Ii. memcached providers

The memcached client I use is memcached providers. After downloading the client, you will find that memcached providers has provided support for Distributed sessions. If you do not use memcached providers, refer to memcached tip 1: Use memcached providers. The example provided by memcached providers is to store sessions directly in the database. We can configure it to store sessions in the distributed session memory, that is, modify dbtype from SQL to none. :

The distributed session provided by memcached providers has nothing special, because the sessionstateprovider type provided by memcached providers implements ASP. the abstract class sessionstatestoreproviderbase in. net. We can see that the session processing class specified in the configuration file is sessionstateprovider. Therefore, Asp. net will consciously use sessionstateprovider to process all sessions after receiving requests from the client, which is exactly the same as this class, the session is read and stored in memcached. (If SQL is set, the session is stored in the sqlserver database ).

The setting and reading of sessions are no different from those of traditional systems. Read:

View sourceprint?

Session ["sname2"] = "sluminjxxi ";

Session. Timeout = 2;

Take:

View sourceprint?

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

 

Iii. Why should I configure SQL statements?

The disadvantage of traditional session exists when dbtype is set to none only. What if memcached's memory reaches the upper limit? Memcached uses the LRU elimination algorithm (which has not been used for a long time). Here, we don't need to go into details about the mechanism of this algorithm in memcached. We just need to know what kind of mechanism it is like when the memory is tight, even if the session time is not reached, memcached may kill it. Therefore, it is safe to add persistent storage of sqlserver under memcached. If the cache hits, the cache will be taken directly. If the cache is dead, it will be confirmed again in the database. Of course, this will cause some performance loss, but it is a safer approach.

Some scripts for Session Initialization are provided in the download file provided by memcached providers. After the script is correctly executed, it will generate a table such as tblsessions and several stored procedures:

Tblsessions stores separate sessions as follows:

 

4. memcached providers bug

In the current memcached providers (version 1.2), there is a bug about sessionstateprovider (29520-trunk) (I have submitted it to codeplex and believe their next version should be corrected. If we test the session expiration time, we find that after a refresh, it will always be 20 minutes (that is, the default value ). This is because in the releaseitemexclusive overload method (this method is used to release the lock on the items in the session data storage area), there is no expiration time for session re-storage, as shown below:

The source code provided by memcached providers is commented out, and the correct one should be the one I corrected. With the corrected DLL, everything is complete.

 

V. scalability of sessions stored in databases

With the increase in access traffic (of course, to this extent, it indicates that the website is very successful and most websites do not need to consider this step), even if we use memcached as the cache, using a single SQL Server to store sessions still brings about performance problems. In this case, we can adopt a horizontal partition architecture for database design, that is, according to a certain algorithm (according to sessionid, or User Name) to store sessions in different databases. At this time, if we still use memcached providers, we must further modify the source code, which originally supported a single sqlserver server and programming to support multiple servers. Of course, if you do not like sqlserver, you can also change it to support MySQL, MongoDB, any custom key-value framework, and so on. If this is not the case, it will not be shown yet.

The first part of this series:

1: ASP. NET performance optimization-Build Custom File Cache

2: ASP. NET performance optimization to allow the browser to cache dynamic web pages

3: ASP. NET performance optimization to reduce requests

4: reverse proxy cache for ASP. NET performance optimization

5: local cache for ASP. NET performance optimization

This article is first published on agilesharp-entrepreneurial push Platform