我们看到，在负载下，会话数据已损坏或丢失，但会话本身仍然存在。
我们的网站托管在运行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相同的数据，但正如我所说，我们无法在那里重现它。
我非常感谢任何人的见解......
答案 0 :(得分：1)
根据迄今为止收集到的所有信息，我将以有根据的猜测回答问题所在。
会话可能会以某种方式到期。
应用程序池回收不是导致会话到期的唯一因素。而且，正如Hanselman will tell you一样，当您将InProc会话管理与高容量相结合时，这是一种常见的情况。
修改：查看older blog post for IIS6详细说明如何确定此类会话丢失的原因，尤其是影响特定用户的会话，而不仅仅是所有会话，因为也发生了。感兴趣的部分就在Application_End代码片段谈论Web Gardens之后。我已经找到了类似于此的新信息，我真正发现的所有问题都是answer to another question here on SO。