Session
The session state options offered by ASP.NET will meet any scenario you need, but there are considerations to selecting between them which are very application specific and we would need a lot more detailed information on the application to make a firm recommendation. To give the general gist however:
1) In-proc state
the good
- fastest option. Can store non-serializable obects
the bad
- As you are load balanced, you need to have affinity on the load balancer so that every request from the same client comes back to the same web server. (reduces the effectiveness of your load balancer)
- You cannot use web gardening (because requests will be round-robin allocated to the worker processes in a single server)
- You cannot really use IIS6 process recycling to keep the web app worker processes happy in case of dire issues (session state would be lost)
- state data will consume virtual address space in the worker process, which could lead to memory issues under some circumstances
- worker process crashes (or restarts) will lose everyone's state
2) State Server
the good
- you can use web gardening
- load balancer affinity is unnecessary if you have the state server on a single separate machine used by all web servers
- you can use process recycling with no user impact
- crashes will only affect requests in-flight
the bad
- objects stored need to be serializable
- may be slower than in-proc
- could still potentially run out of memory space in high session count, large state size scenarios (not as badly as in-proc however)
3) SQL server
the good
- same as state server but more scalable
- is usually on a single, separate machine already, so load balancer affinity is not necessary
the bad
- objects stored need to be serializable
- may be slower than in-proc
From our experience here, which admittedly tends to be based predominantly on large-scale systems with high load that are seeing problems, I think we'd all recommend an out-of-process solution because of how forgiving it is when problems occur, and because it's a lot more scalable than in-proc.
You should test in-proc and at least one of the out-of-proc types. If the performance of the out-of-proc solution is adequate, then definitely go with this.
If the site has problems under load when it goes live (which is when we normally see such), having in-proc session state neutralizes most of the mitigation strategies that IIS6 affords us (recycling and gardening) and consequently usually leads to more downtime for the users.
>>>>>>>>>>>>>>>>>>
Either of the out-of-process options is ok. Having session out-of-proc allows you to take advantage of:
a) IIS worker process recycling – helps reliability.
b) “Random” (rather than “sticky”) load balancing – typically has a desirable impact on scalability.
I’d recommend SQL Server – most of our customers who are using session state in a load balanced config use SQL.
If they use either out-of-proc option, make sure they sync the app path in the IIS metabase and <machineKey> in machine.config on each server in the cluster. More info in following KB:
http://support.microsoft.com/kb/325056/en-us
Besides, if they install SQL for session then maybe they can use it for their data.
Red hat / apache app server – they need to have an appropriate support arrangement with an appropriate vendor for these non-MS components.