我刚刚发现了所有ASP.NET网站速度慢的原因，我正在想办法解决这个问题。

Question

我刚刚发现了所有ASP.NET网站速度慢的原因，我正在想办法解决这个问题。我刚刚发现ASP.NETWeb应用程序中的每个请求在请求开始时都会获得一个会话锁，然后在请求结束时释放它！如果你失去了这方面的影响，就像最初对我一样，这基本上意味着以下几点：任何时候，ASP.NET网页都需要很长时间来加载(可能是由于数据库调用缓慢或其他原因)，用户决定要导航到另一个页面，因为他们厌倦了等待，他们不能！ASP.NET会话锁强制新页请求等待，直到原始请求完成其缓慢的加载。阿罗。当UpdatePanel加载缓慢时，用户决定在UpdatePanel完成更新之前导航到另一个页面.他们不能！ASP.NET会话锁强制新的页请求等待，直到原始请求完成其痛苦的缓慢加载。双重阿罗！那么有什么选择呢？到目前为止，我已经想出：实现ASP.NET支持的自定义SessionStateDataStore。我还没有找到太多可以复制的东西，而且似乎风险很高，而且很容易搞砸。跟踪所有正在进行的请求，如果来自同一用户的请求来自同一个用户，则取消原始请求。看起来有点极端，但它会起作用的(我想)。不要用会话！当我需要用户某种状态时，我可以使用Cache代替，以及通过身份验证的用户名上的关键项，或者其他类似的东西。又有点极端了。我真不敢相信ASP.NETMicrosoft团队会在4.0版的框架中留下如此巨大的性能瓶颈！我漏掉了什么明显的东西吗？在会话中使用线程安全集合有多难？

Answer 1

如果您的页面不修改任何会话变量，则可以选择退出大多数此锁。

<% @Page EnableSessionState="ReadOnly" %>

如果您的页面没有读取任何会话变量，则可以选择完全退出该页的此锁。

<% @Page EnableSessionState="False" %>

如果您的页面没有使用会话变量，只需关闭web.config中的会话状态即可。

<sessionState mode="Off" />

我很好奇，如果不使用锁，您认为“线程安全集合”会做什么来实现线程安全？

编辑：我可能应该解释一下我所说的“选择退出大部分锁”。任意数量的只读会话或非会话页都可以同时处理给定会话，而不会相互阻塞。但是，在所有只读请求完成之前，读写会话页无法开始处理，并且在运行时，它必须具有对该用户会话的独占访问权限，以保持一致性。锁定单个值将不起作用，因为如果一个页面将一组相关值作为一个组进行更改，该怎么办？如何确保同时运行的其他页面将获得用户会话变量的一致视图？

如果可能的话，我建议您尝试在会话变量设置之后尽量减少对它们的修改。这将允许您使您的页面的大部分只读会话页，增加了多个同时来自同一用户的请求不会彼此阻塞的机会。