Session State Server vs Custom Session State Provider_问答_开发者

I have been tasked to scale out the session for an application. From my research the most obvious choice is to use the State Server session provider, because I don't need the users sessions to persist (SQL Server Session provider)

About the app:

Currently using InProc sess开发者_如何学Goion provider
All objects stored in session are serializable
All objects are small (mostly simple objects (int, string) and a few simple class instances)

Before I dive head-first into the IT side of things and with the ability to provide a custom session provider with ASP.NET 4, should I even consider a custom session state provider. Why or why not? Are there any "good" ones out there?

Thanks! User feedback:

Why are we using session: persistence of data between postbacks (e.g. user selections)
How: user makes a selection, selection is stored. User leaves a page and returns, selections are restored. etc. etc.
Will be creating a web farm

I've provided some links you can read up on on properly scaling session using the state server.

Useful links from Maarten Balliauw's blog:

http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-%28aspnet_state%29.aspx
http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning.aspx
http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning-using-State-Server-Load-Balancing.aspx

My State Server related projects:

http://www.codeproject.com/KB/aspnet/p2pstateserver.aspx (latest code at https://github.com/tenor/p2pStateServer)
http://www.codeproject.com/KB/aspnet/stateserverfailover.aspx

Hope that helps.

It depends on what you mean by "scaling" session storage. If your simply talking about session state performance, your not going to beat the in-process session state provider. Switching to the State Server provider will actually make things slower -- due to the extra overhead of serializing and transferring objects across process boundaries.

Where the State Server can help you scale, is that it allows multiple machines in a load balanced web-farm to share a single session state. It is limited by machine memory, however, and if you will have lots of concurrent sessions you may want to use the SQL Session State provider.

For the most performance in a web farm, you can also try using AppFabric as was previously suggested. I haven't done it myself but it is explained here.

Also, here's a link for using Memcached as a Session State provider. Again, I haven't used it, so I can't offer an opinion on it...

EDIT: As @HOCA mentions in the comments, there are 3rd party solutions if cost isn't an issue. One I've heard of (but not used) is ScaleOut SessionServer.

I would highly recommend that before you look in to scaling out session that you first evaluate whether session was even needed in the first place.

Session variables are serialized and deserialized for every single page load whether the page uses that data or not. (EDIT: Craig pointed out that you have some level of control over this in .net 4 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatebehavior.aspx However, this still has drawbacks, see comments to this answer.)

For single server instances this is okay as you are just pulling it from the local memory of your web server. The load on these apps tend to be pretty small so caching user specific information locally makes sense.

However, as soon as you move storage of session to another server you have increased the network requirements and page load times of your application. Namely, every page will result in the session data to be moved from the remote server, across the network wire, and into memory of the web server.

At this point you have to ask yourself: is the load to pull this information from the database server directly as necessary more than pulling it from the session server every single time?

There are few instances where pulling it from the database server as needed takes longer or results in more traffic than grabbing it from a remote session server.

Bearing in mind that a lot of people set up their database server(s) to also be session servers and you start to see why use of session doesn't make any sense.

The only time I would consider using session for load balanced web apps is if the time to acquire the data exceeded a "reasonable" amount of time. For example, if you have a really complex query to return a single value and this query would have to be run for lots of pages. But even then there are better ways that reduce the complexity of dealing with remote session data.

I would advise against the use of session state, regardless of the provider.

Especially with your "very small objects" use viewstate. Why?