asp.net 会话
I have a love/hate relationship with the ASP.NET Session. It's such a convenient place to put things, but when you start putting applications into production there are a number of less-than-obvious edge cases that can come up and bite you.
我与ASP.NET会话有恋爱关系。 在这里放东西很方便，但是当您开始将应用程序投入生产时，会出现很多不太明显的边缘情况，这些情况可能会咬住您。
Most often the Session is used when managing state over a long process like a multi-step wizard or questionnaire. However, when people use the Session, they often lean on it a little. They'll bake it into their design so deep that when it doesn't work, they're screwed. That's not to say they shouldn't be able to lean on it, I'm just saying that there's a lot of things going on with Session (not just on ASP.NET, but other frameworks as well) in order to get it to look seamless.
在通过多步骤向导或调查表等长期流程管理状态时，通常会使用会话。 但是，当人们使用Session时，他们通常会稍微倾斜一下。 他们会将其烘烤到其设计中如此之深，以至于当它不起作用时，它们就会被拧紧。 这并不是说他们不应该依靠它，我只是说Session有很多事情(不仅在ASP.NET上，而且在其他框架上)也可以解决。看起来无缝。
内置选项 (Built in Options)
ASP.NET offers three options (four if you count rolling your own).
ASP.NET提供了三个选项(如果您考虑自己滚动，则提供四个选项)。
Inproc - The default, and usually works fine. However, you can get into trouble in a few scenarios.
Inproc-默认值，通常可以正常工作。 但是，在某些情况下您可能会遇到麻烦。
- Web Farms - If you have more than one web server, it's important to remember that your users may not "stick" to the same webserver with each request. Some routers offer Sticky-Sessions or the ability to "pin" a user to a server. This works well if the router uses cookies as its key, but it's less reliable if the router uses IP address/source port as the key as these may change, especially if the user is behind a mega-proxy. Web场-如果您有多个Web服务器，请记住，您的用户可能不会在每次请求时都“坚持”到同一Web服务器，这一点很重要。 某些路由器提供粘性会话或将用户“固定”到服务器的功能。 如果路由器使用cookie作为其密钥，则此方法效果很好，但是如果路由器使用IP地址/源端口作为密钥，则可靠性会降低，因为它们可能会更改，尤其是在用户位于超级代理之后的情况下。
- Web Gardening - If you've setup IIS to run multiple instances of the IIS Worker Process on a single multi-proc machine, this is the equivalent of running a Web Farm, just on one machine. This technique is usually only useful when you've got a very CPU-intensive application - in other words, don't just turn on Web Gardening and expect your problems to get better instantly. It's subtle. Web园艺-如果已将IIS设置为在一台多进程计算机上运行IIS Worker进程的多个实例，则等效于仅在一台计算机上运行Web场。 该技术通常仅在拥有非常占用CPU的应用程序时才有用-换句话说，不要只是打开Web Gardening并期望您的问题会立即得到改善。 真微妙
Unexpected Process Recycling - IIS6 had some wonky defaults and would recycle the AppPool or Process when some certain limits were hit, like after x number of requests or after 20 minutes. This is the classic "flaky session state is expiring" issue that lots of folks hit. You'll be more likely to see this if you've got really long running processes where users are logged in for long periods of time.
意外的进程回收-IIS6具有一些奇怪的默认值，并且在达到某些特定限制时(例如，在请求数量x之后或20分钟之后)，IIS6将回收AppPool或进程。 这是许多人都遇到的经典“不稳定的会话状态即将到期”问题。 如果您的进程运行时间非常长，而用户长时间登录，则更有可能看到此消息。
Inproc - The default, and usually works fine. However, you can get into trouble in a few scenarios.
Inproc-默认值，通常可以正常工作。 但是，在某些情况下您可能会遇到麻烦。
Out of proc - A good next step, this moves session out to a Windows Service. You can run one per Web Farm (meaning, you've got multiple machines but one instance of this service) and your session data will survive process recycles, but not system reboots. This is useful for both Web-Gardening and Web-Farming.
Out proc-下一步，将会话移至Windows Service。 您可以在每个Web场中运行一台(这意味着您有多台计算机，但是此服务只有一台实例)，并且会话数据将在过程循环中幸存下来，但在系统重新启动后仍然有效。 这对于Web园艺和Web种植都是有用的。
- Folks usually forget to mark their objects as [Serializable] which basically gives your objects "permission" to leave their process space and be stored in memory in the State Service. If you've got a high-traffic site you might want to avoid storing complex objects and object graphs as you'll pay for it on the serialization. Of course, with all things, measure everything! You'll get best performance if you stick with basic types like strings, ints, etc. 人们通常忘记将其对象标记为[可序列化]，这基本上使您的对象具有“许可”离开其处理空间并存储在State Service的内存中的能力。 如果您有一个人流量大的网站，则可能要避免存储复杂的对象和对象图，因为您需要在序列化中为此付费。 当然，用万物来衡量一切！ 如果坚持使用字符串，整数等基本类型，则将获得最佳性能。
UPDATE: I wanted to update this post and point folks to Maarten Balliauw's most excellent series on Out of Proc Session State (StateServer). He covers the basic setup, which is unremarkable, but then digs into the advanced stuff including "partitionResolvers" which I am ashamed to say I hadn't heard of! Recommend.
更新：我想更新这篇文章，并向人们介绍Maarten Balliauw关于Out of Proc Session State(StateServer)的最出色的系列。 他介绍了基本的设置，该设置并不引人注目，但是随后深入研究了高级内容，包括“ partitionResolvers”，我很say愧地说我没听说过！ 推荐。
SQL Server - The most robust, but now you'll pay for not only serialization, but storage. However, SQL Server is a highly tuned system and if you've got a site with any significant traffic I really recommend just skipping out-of-proc and putting your session state into a SQL Server with a lot of memory. Rather than trusting ASP.NET out of proc Session State Server to be a small database, leave the database work to the databases.
SQL Server-最强大的功能，但现在您不仅要支付序列化费用，还需要支付存储费用。 但是，SQL Server是一个高度优化的系统，如果您的站点流量很大，我真的建议您跳过进程外访问并将会话状态放入具有大量内存SQL Server中。 不要将proc Session State Server之外的ASP.NET信任为小型数据库，而应将数据库工作留给数据库。
The benefits of SQL Server for your Session State include surviving process recycles and reboots. but more importantly using removes a lot of variables from your troubleshooting in the sense that you no longer worry about the storage of your Session, now you just need to worry if your Session Cookies are getting passed back and forth from browser to server.
对于您的会话状态，SQL Server的好处包括存活的进程回收和重新启动。 但更重要的是，使用可以从故障排除中删除很多变量，因为您不再担心会话的存储，现在您只需要担心会话Cookie是否从浏览器到服务器来回传递。
- Make sure you're using Windows Integrated Security and that you decide if you want ASP.NET to store Session in tempdb (which won't survive a SQL recycle) or a dedicated database (my recommendation). 确保您使用的是Windows Integrated Security，并确定是否要ASP.NET将Session存储在tempdb(无法通过SQL循环生存)或专用数据库(我的建议)中。
SQL Server - The most robust, but now you'll pay for not only serialization, but storage. However, SQL Server is a highly tuned system and if you've got a site with any significant traffic I really recommend just skipping out-of-proc and putting your session state into a SQL Server with a lot of memory. Rather than trusting ASP.NET out of proc Session State Server to be a small database, leave the database work to the databases.
SQL Server-最强大的功能，但现在您不仅要支付序列化费用，还需要支付存储费用。 但是，SQL Server是一个高度优化的系统，如果您的站点流量很大，我真的建议您跳过进程外访问并将会话状态放入具有大量内存SQL Server中。 不要将proc Session State Server之外的ASP.NET信任为小型数据库，而应将数据库工作留给数据库。
故障排除 (Troubleshooting)
There's a number of things that can go wrong, some of which I mention above, but here's what I usually run through when troubleshooting things.
有很多事情可能会出错，我上面已经提到了其中一些问题，但是这是我对问题进行故障排除时通常要经历的事情。
Is the ASP.NET SessionID Cookie actually moving back and forth between browser and server. This can be confirmed by:
ASP.NET SessionID Cookie是否实际上在浏览器和服务器之间来回移动。 可以通过以下方式确认：
- Using an HTTP Sniffer like ieHttpHeaders or HttpWatch or Fiddler and confirming that the Session ID cookie's value isn't changing between requests. 使用HTTP嗅探器(例如ieHttpHeaders或HttpWatch或Fiddler)并确认会话ID cookie的值在两次请求之间没有变化。
- Confirming that the cookie isn't being blocked by IE, privacy settings, lack of a P3P policy document, local firewall like ZoneAlarm or Symantec, or a corporate proxy with an attitude problem. 确认Cookie没有被IE，隐私设置，缺少P3P策略文档，本地防火墙(如ZoneAlarm或Symantec)或存在问题的企业代理所阻止。
- Is IIS recycling the AppPool or Worker Process? Confirm the settings in IIS manager and make sure they are right for what you're doing. IIS是否正在回收AppPool或Worker进程？ 在IIS管理器中确认设置，并确保它们适合您的工作。
- Is the session timing out? Are you sure you're hitting the same VDir from whence you came and successfully resetting the sliding expiration on the Session ID? 会话超时了吗？ 您确定您从来时就打了相同的VDir，并成功重置了会话ID的滑动到期时间吗？
Is some other thing like an Ajax call or IE's Content Advisor simultaneously hitting the default page or login page and causing a race condition that calls Session.Abandon? (It's happened before!)
是否有其他事情(例如Ajax调用或IE的Content Advisor)同时击中默认页面或登录页面并导致调用Session.Abandon的竞争状况？ (以前发生过！ )
At my last company Session became such a hassle for large high traffic applications that we just stopped using in-proc and started exploring alternatives.
在我的上一家公司中，Session对于大型高流量应用程序变得如此麻烦，以至于我们只是停止使用In-proc，而开始探索替代方案。
第三党会议的某些状态选项 (Some 3rd Party Session State Options)
NCache from Alachisoft - An in-memory object cache that's distributed across your web farm. Think of it like Out of Process Session State, but distributed/clustered in their Enterprise Edition.
Alachisoft的NCache-在整个Web场中分布的内存中对象缓存。 可以将其视为“进程外会话状态”，但在其企业版中是分布式/群集的。
ScaleOut Software SessionServer - Fast, scalable in-memory storage that is distributed across machines. Full Disclosure: we worked with these guys while I was at Corillian, but never put them into production.
ScaleOut软件SessionServer-快速，可扩展的内存中存储，分布在计算机之间。 全面披露：我在Corillian时曾与这些人合作，但从未将它们投入生产。
Memcached Session State Provider - Fahad has created ASP.NET Session State providers that will talk to memcached, a very popular distributed memory caching system originally created for LiveJournal.com and now used all over.
Memcached会话状态提供程序-Fahad已创建了ASP.NET会话状态提供程序，该程序将与memcached对话， memcached是一种非常流行的分布式内存缓存系统，最初是为LiveJournal.com创建的，现在已被广泛使用。
Related Links you might enjoy
您可能喜欢的相关链接
Moving ViewState to the Session Object and more Wrongheadedness
ViewStateUserKey and "Invalid_Viewstate" when posting back during Forms Authentication
CSI：ASP.NET-一种来自Internet Explorer(IE)的双重HTTP GET导致FormsAuthentication和我的理智的问题
How do you manage state at your company?
您如何管理公司的状态？
翻译自: https://www.hanselman.com/blog/troubleshooting-expired-aspnet-session-state-and-your-options
asp.net 会话
271
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
