Background
In ASP.NET State Management is one of the most common requirement for many web application. This enables developers to share data across user sessions (session state), across requests on the same web server using Caching and Application State. ASP.NET framework offers various options to use state management techniques to scale the state management. In this post I am going to highlight the issues I faced recently with the session state management.
Session State Management
ASP.NET offers different options to scale the session state by means of InProc, Out of Proc and SQL Server State modes. All these work very well with web sites. We needed to use the state information in a WCF web service. WCF does offer state maintenance feature. But this is always stored in the servers memory using InProc mode. Hence this solution cannot scale up to a web farm or web garden mode of deployment which are used for failover scenarios.
We can overcome the this limitation by enabling the ASPNET compatibility mode for WCF service by decorating the service with the attribute. This MSDN article talks more about this. This ensures that when the WCF service is hosted in IIS it leverages the features available to ASP.NET pipeline.
In our project we use a Windows 2008 cluster and have multiple webservers which are load balanced using the content switch. We decided to store the session data on the cluster environment as out of Proc mode. But unfortunately the ASP.NET state service is not cluster aware. This means that if the primary machine fails in the cluster and it switches to the secondary machine, the state information does not get copied over to the secondary machine automatically. Due to this reason it can’t scale out very well.
Conclusion
I wish Microsoft guys had given a thought to the ASP.NET state service and made it work even in a clustered environment. In absence of that we can try out the possibility of using ASP.NET state service in SQL Server mode. This works well in a clustered environment as the data is stored in physical tables in SQL Server database. The SQL server can be set up in a cluster and provides highest scalable option due to failover capability. But in terms of application performance it might get hit as the state service is slowest in the SQL server mode.
Alternately we can try other scalable options like distributed cache. there are multiple choices available if somebody wishes to try any of them
I haven’t tried these so far due to time constraints. But for the next phase of the project I’ll be evaluating all these.
Hope this helps. Until next time happy programming :)
my vote is for NCache. I've used NCache during one of my projects and i was very happy with its results. i also like NCache because of rich topologies which it offers.
ReplyDeleteMemcached is an open source caching solution while velocity is still finding its place in the distributed caching niche as there are already some very mature caching products are available which are doing very good job. As far as NCache and ScaleOut are concerned, both are the market leaders in field of distributed caching. NCache is famous among the developers because of its wide range of topologies. It also offer appliance for java and Memcached.
ReplyDelete