我们发现，在负载下， session 数据损坏或丢失，但 session 本身仍然存在。
我们的网站托管在运行 ASP.Net 4.0 的 IIS 7 上，并在网络场中使用 InProc session 状态，Cisco ACE Appliance 负载平衡器后面总共有 4 台服务器。
目前该问题是随机的，我们无法随意重现该问题。该网络应用程序在过去七个月中一直正常运行。
我们意识到 Microsoft 不建议将 InProc 与网络场一起使用，即使正在使用粘性 session 。
我们确实有一个实验室环境，与我们的生产环境相当相同，但无法在大量负载下重现(我们使用 WAPT)。
在我们的生产环境中，我们尝试仅隔离负载均衡器后面的一台服务器，以消除负载均衡器本身引起的“服务器跳跃”。然而，即使在一台服务器上运行，问题仍然存在。我们在生产中根本没有看到任何 AppPool 或 IIS 回收发生。作为标准做法，我们每天凌晨 3 点(美国东部时间)回收生产应用程序池，并且操作系统已享受数月的正常运行时间。
session 中存储的是各种各样的对象，从简单类型(整数和字符串)到整个购物车(复杂的对象图)，甚至是用户控件 (.ascx) 实例。由于无法轻松序列化其中许多对象，因此我们无法在合理的时间内切换到进程外 session 存储。
有人建议尝试使用 Fiddler 捕获 HTTP session 。运行 Fiddler 的问题是我们无法自己故意重现该问题。因此，这使得我们无法在故障事件发生时捕获其 HTTP 跟踪。我们实验室中 WAPT 的跟踪日志可能会提供与 Fiddler 相同的数据，但正如我所说，我们无法在那里重现它。
我非常感谢任何人可能有的见解......
最佳答案
根据迄今为止收集到的所有信息，我将对问题所在进行有根据的猜测来回答。
session 可能会以某种方式过期。
应用程序池回收并不是唯一可能导致 session 过期的因素。并且，如 Hanselman will tell you ，当您将 InProc session 管理和高容量结合起来时，这种情况很常见。
编辑:看看 older blog post for IIS6详细说明了如何确定此类丢失 session 的原因，尤其是影响特定用户(而不仅仅是所有 session )的 session ，因为这种情况也可能发生。感兴趣的部分就在讨论网络花园的 Application_End 代码片段之后。我寻找了一条与此类似的新信息，我真正能找到的所有讨论所有问题的是 answer to another question here on SO .
关于ASP.NET session 在负载下损坏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7169711/