What is the overhead performance penalty for running Session State Server instead of InProc? Is it significant? I understand that you can restart w3wp with the state server and retain all session state - is that the only advantage over InProc?
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- How to store image outside of the website's ro
- 'System.Threading.ThreadAbortException' in
- Request.PathInfo issues and XSS attacks
- How to dynamically load partial view Via jquery aj
相关文章
- asp.net HiddenField控件扩展问题
- asp.net HiddenField控件扩展问题
- Asp.Net网站无法写入错误日志,测试站点可以,正是站点不行
- asp.net mvc 重定向到vue hash字符串丢失
- Page指令 的EnableSessionState="ReadOnly",怎么在web.confi
- FormsAuthenticationTicket expires too soon
- “Dynamic operations can only be performed in homog
- What is the best way to create a lock from a web a
It depends on your deployment plans: on a single server, the penalty is small, but the benefit is equally limited: your session state survives process recycles (as mentioned) but that's about it. You'll have some cross process marshalling with StateServer mode, so expect some additional cpu load, nothing too impressive.
In a web farm/load balanced setup InProc won't work, unless you can configure sticky sessions/server affinity. Be mindful of the fact that the StateServer node itself can become a single point of failure, so be sure to compensate for that. Having said that, the latency of a StateServer is in general much less (= better) than when you use SQLServer mode.
Make sure that your code/site gracefully handles lost state, regardless of where you store the data.
If you have a load balance setup (without the use of sticky sessions) you cannot use InProc since (based on your load balance setup of course) you might switch between nodes.
Recycles of the worker process (but that is of course the same as restarting w3wp) will also kill your session when it is InProc.