Mar*_*man 7 asp.net iis session iis-7 corruption
我们看到,在负载下,会话数据已损坏或丢失,但会话本身仍然存在.
我们的网站托管在运行ASP.Net 4.0的IIS 7上,并在Web场中使用InProc会话状态,共有4台服务器位于Cisco ACE Appliance负载均衡器后面.
此时问题是随机的,我们无法随意重现问题.此Web应用程序在过去七个月中一直运行正常.
我们意识到,即使正在使用粘性会话,Microsoft也不建议将InProc与Web场一起使用.
我们确实有一个与我们的生产环境完全相同的实验室环境,但是无法在大量负载下重现(我们使用WAPT).
在我们的生产环境中,我们尝试仅在负载均衡器后面隔离一个服务器,以消除由负载均衡器本身引起的"服务器跳跃".但是,即使在一台服务器上运行,问题仍然存在.我们在生产中根本看不到任何AppPool或IIS回收.作为标准做法,我们每天凌晨3点开始回收生产应用程序池,并在操作系统上享受数月的正常运行时间.
会话中存储的是各种各样的对象,从简单类型(整数和字符串)到整个购物车(复杂的对象图),甚至是用户控件(.ascx)实例.由于无法轻松序列化许多这些对象,我们无法在合理的时间段内切换到进程外会话存储.
有人建议尝试使用Fiddler捕获HTTP会话.运行Fiddler的问题是我们不能故意自己重现这个问题.因此,这使得我们无法在发生故障事件时捕获HTTP跟踪.我们实验室中来自WAPT的跟踪日志可能会提供与Fiddler相同的数据,但正如我所说,我们无法在那里重现它.
我非常感谢任何人可能拥有的见解......
根据迄今为止收集到的所有信息，我将对问题所在进行有根据的猜测来回答。
该会话可能会以某种方式过期。
应用程序池回收并不是唯一可能导致会话过期的因素。而且，正如Hanselman 会告诉您的那样，当您将 InProc 会话管理和高容量结合起来时，这种情况很常见。
编辑：看一下IIS6 的一篇较旧的博客文章，其中详细介绍了如何确定此类会话丢失的原因，尤其是那些影响特定用户（而不仅仅是所有会话）的会话，因为这种情况也可能发生。感兴趣的部分就在Application_End讨论网络花园的代码片段之后。我寻找了与此类似的更新信息，我真正能找到的所有讨论的问题都是对 SO 上另一个问题的答案。