Session state frequently ends up on a busy SQL Server. What seemed like a good idea in development turns into a problem in production. While there are valid business reasons for persisting session state to permanent storage; there are equally valid reasons to avoid using SQL Server as the permanent storage. We’ll investigate why session state poses problems for SQL Server and cover an alternate solution that allows for persistent session state. This talk is for developers and DBAs who want a better way to safely track ASP.NET session state.
Hi! I’m Brent Ozar.
I make Microsoft SQL Server go faster. I love teaching, travel, cars, and laughing. I’m based out of Las Vegas. He/him. I teach SQL Server training classes, or if you haven’t got time for the pain, I’m available for consulting too.
Want to advertise here and reach my savvy readers?
8 Comments. Leave new
Jeremiah,
Great video about session state, and a great use case for Riak. What’d be really interesting though would be a comparison of different NoSql session states for performance.
I mean I totally expect Riak, Couch, MongoDB, RavenDB, etc to be a better session state solution than SQL Server. However, what I’d really like to see is someone compare these head to head and give me some benchmarks.
I agree. It’d be nice if someone were to put that together. I suspect there will be interesting scenarios were each solution will perform better.
It’s very interesting how differently DBAs view issues of this kind from Developers. It sounds very easy to say “well, Riak is ridiculously simple (for the DBA) at the cost of a little bit of Developer productivity”. Huh? Maybe if the problem is that the DBA struggles with managing two Microsoft Products which are designed to integrate together, the answer might be that the DBAs need better training. Session State, also, I should add, is not a “low risk place” to start experimenting. It’s actually one of the higher risk places to experiment because issues with Session State rarely show up in test systems, and can very quickly alienate customers. Very interesting how DBAs view the world.
You’re right, we are assessing risk in different ways. And, to be fair, I should have said “lower risk” since risk is relative. With a bad session state implementation, or attacks on a web server, there are risks that a malicious user can become aware of other users’ session or that users may see erratic data.
When I look at moving session state backing store, I see an opportunity to slowly migrate customers from one system to another. Or, better yet, route data to two systems simultaneously to see how both systems perform under production load. Risk is largely in how you manage it.
As far as better training, no amount of training will counteract the physical effects that busy session state has on disks. There are a number of products out there, Microsoft developed or not, that have similar effects. Managing them is like managing risk – the business needs to make decisions based on a cost benefit analysis. Does session state need to live on a six figure SAN or can performance be achieved through other means? What level of redundancy does session state need? What are the uptime requirements? Answering these kinds of questions should be the driver for data storage, not “Hey, we found this database in the corner of the data center, let’s use it!”
Based on what I have heard, I don’t see that RIAK, etc will scale out so that the sessionstate data is replicated to another sessionstate server to handle side outages without impacting customer experience too drastically. Do you know if that is a possibility?
The open source version of Riak only has single-site durability. Keep in mind that within that single site, you’ll have 5+ machines serving up session state with 3 copies of your data in that session state cluster. DC failure is pretty much the only thing that’s going to take out a cluster. That being said, Riak Enterprise provides support for replicating clusters between multiple sites.