我有一个使用带有“InProc”会话处理的 ASP.NET 的 Web 应用程序。通常情况下，一切正常，但是每天运行几百个请求所需的时间比正常情况要长得多。在 IIS 日志中，我可以看到这些页面（通常需要 2-5 秒才能运行）运行了 20 多秒。
我在详细模式下启用了失败的请求跟踪，发现延迟发生在 AspNetSessionData 部分。在下面显示的示例中，AspNetSessionDataBegin 和 AspNetSessionDataEnd 之间有 39 秒的间隔。
我不确定下一步该怎么做。我找不到造成这种延迟的任何原因，也找不到更多可以启用的日志记录功能来告诉我这里发生了什么。有谁知道为什么会发生这种情况，或者对我可以采取哪些其他步骤来查找问题有任何建议？
我的应用程序通常为每个用户在会话中存储 1-5MB，主要是用于搜索的缓存数据。服务器有足够的可用内存，并且只运行大约 50 个用户。
这可能是由会话状态的锁争用引起的。看看 MSDN 的ASP.NET Session State Overview的最后一段。另请参阅K. Scott Allen关于此主题的有用帖子。
如果页面使用 EnableSessionState="True" 注释（或继承 web.config 默认值），则对该页面的所有请求都将获取会话状态的写锁定。所有其他使用会话状态的请求——即使它们没有获得写锁——都会被阻塞，直到该请求完成。
如果页面使用 EnableSessionState="ReadOnly" 进行注释，则该页面将不会获得写锁，因此不会阻塞其他请求。（虽然它可能被另一个持有写锁的请求阻塞。）
要消除这种锁争用，您可能希望围绕HttpContext.Cache对象或静态WeakReference实现自己的 [细粒度] 锁定。后者可能更有效。（参见Richard Kiessig的Ultra-Fast ASP.NET第 118-122 页。）
您可能会遇到应用程序池允许消耗的最大内存量，这会导致应用程序池重新启动（这将导致您在访问会话时看到延迟）。服务器上的内存量不会影响 ASP.NET 可以使用的内存量，这在 machine.config 中的 memoryLimit 属性和 IIS 6.0 中稍后在 IIS 本身中使用“使用的最大内存”属性进行控制。除此之外，您是否考虑过每个用户使用 5 MB 会话内存的替代方案？这根本无法很好地扩展，并且在负载下可能会导致很多问题。缓存可能是更有效的解决方案吗？搜索是否需要很长时间以至于您需要执行此操作，是否可以优化 SQL/数据库设置以加快查询速度？