Allowing Session in a Web Farm? Is StateServer Good Enough?

Question

First of all to give you a bit of background on the current environment. We have a number of ASP.NET applications, all of which use session for certain aspects. We are \"L

Answer 1

I would like to another one more point to the accepted answer:

• Make sure the version of framework dlls is the same.

In my case the System.Web dll versions were different as a few windows updates were skipped on one of the servers of the farm.

Answer 2

In my experience we've found out that native state server or even using SQL Server for sessions is a very scary scenario as both have issues (mainly performance). By the way, we are also using sticky sessions.

I think you can explore other products for this to achive the absolute best. A free option would be Velocity but it is still not released. And another comprehensive but proven product will be (Very expensive actually) NCache. THis will even help in your serilizations with less cost, If you use their API's it will be even better results.

Take a look and see which looks best for you.

About SQL Server, you server will die very soon if you have enough number of hits coming in (I belive you have some hits already which yielded you to do Web Farm or you do it just for the sake of redundancy)

Bottom line: We are evaluating Velocity because NCAchce is really expensive. However advantages are huge.

Answer 3

I have only used sql and in-proc. But these 3 that apply when using sql server apply as well:

• Avoid storing too much information in the session, as it affects both in serialization and data transmitted over the network.
• Make sure you don't have anything that depends on the Session_onEnd. This is just not available for out of process sessions.
• Turn off session on pages that doesn't uses it. This don't make a difference for in-process session, but for out of process it will save you a lot.

Answer 4

We are using StateServer for a very small web farm with only two nodes for a few hundred users.

I'm not responsible for its operation but I remember only two issues in two years where the service had to be restarted because it crashed.

Answer 5

Here is a decent FAQ on asp.net state: http://www.eggheadcafe.com/articles/20021016.asp

From that Article, here is some information on StateServer:

• In a web farm, make sure you have the same MachineKey in all your web servers. See KB 313091 on how to do it.
• Also, make sure your objects are serializable. See KB 312112 for details.
• For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details

Answer 6

Make sure your server etag ids are synchronized across the web farm otherwise caching at client browsers will be upset.

Have you reviewed your code in detail to make sure everything can be serialized out of process and across a LAN efficiently?

Are you solving the main performance problem within your system? I ask because the database is the typical source of contention.

My main motivation for moving away from sticky sessions was operational flexibility i.e. cycle down a problematic server or to deploy a software upgrade. So having implemented a central session state service make sure you take full advantage from an operational stand point.