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 "Load Balanced" over multiple servers due to traffic levels, however, our load balancing is set to use "Sticky Sessions" as currently all web applications are set to use "InProc" for session state.

We are looking at being able to remove the "Sticky Sessions" configuration on our load balancer, as due to our traffic loads servers can and do get overloaded. We want to go with a more balanced approach, but must be able to use session.

I know that SqlServer for session state will work, but for reasons beyond our control, we cannot use SqlServer to store our state. In researching it seems that StateServer is our best bet. We have an additional server, with loads of memory sitting around. This server could be our StateServer for the entire Web Cluster. We just want to know the following things.

1.) Besides any potential serialization issues with the switch from InProc to StateServer, are there any major known issues with losing session objects or generating errors with the above listed environment?

2.) Aside from the single point of failure, and slighly slower performance are there any other gotchas that we need to be aware of with using StateServer.

3.) Are there any metrics that show the performance differences between the three types of state storage?

Sweettempered

How much information is being stored in the session states? – Ingunna

Right now we have no clue. There are well over 150 different applications developed by different groups. – Sweettempered

Answer 1

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

Vaccinia

The last point about the IIS path is interesting, does anyone know if this still applies in IIS7+? Also, how can you check this path in IIS7? – Impolicy

Yes it still applies. See this answer on serverfault for more details. – Humism

You rock. The "Application Path" aka ID's not matching, was my problem. Funny how I had run into this exact problem years ago, had forgotten about, and debugging a weird session anomaly led me here. Thanks much! – Hwahwan

+1 for Application Path, the casing was different on my two servers – Mislead

Answer 2

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.

Inhume

Answer 3

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.

Prowess

Code review is something that will be done, IF we prove that it is possible to fix items. The db is not a bottleneck at all our environment, but heavy unequal load on the web servers. – Sweettempered

Answer 4

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.

Perpetuity

For those looking for caching servers you can also check out SharedCache / Indexxus as well... pretty solid caching tool. – Ronironica

For those looking for a more up-to-date solution: Scott Hanselman did a nice write-up of how to set up the recently released Velocity mem-cache, e.g. as the ASP.NET Session State server. – Humism

We have load tested ASPNet state service against velocity cache (AKA appfabric) the results are stark difference. ASPNet state service outperforms AppFab by massive amount (near 250% faster) and AppFab requires a ton more memory and is more difficult to configure in a cluster. Dont use AppFabric for session state – Adin

Answer 5

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.

Purposive

I see this is an old post, but what were the symptoms when the service crashed? Did you just start seeing "Invalid session state" error messages, or was it more cryptic? – Ingraft

@Ingraft sorry I don't remember but I think it just crashed. – Purposive

Answer 6

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.

Kuenlun