我刚刚发现为什么所有的 ASP.Net 网站都很慢，我正在努力想办法解决这个问题 [英] I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it

问题描述

我刚刚发现 ASP.Net Web 应用程序中的每个请求在请求开始时都会获得一个会话锁，然后在请求结束时释放它！

I just discovered that every request in an ASP.Net web application gets a Session lock at the beginning of a request, and then releases it at the end of the request!

如果这对您没有影响，就像一开始对我一样，这基本上意味着以下内容:

In case the implications of this are lost on you, as it was for me at first, this basically means the following:

• 任何时候加载 ASP.Net 网页需要很长时间(可能是由于数据库调用缓慢或其他原因)，并且用户决定导航到不同的页面，因为他们已经厌倦了等待，他们不能！ASP.Net 会话锁强制新页面请求等待原始请求完成其痛苦的缓慢加载.啊.

• Anytime an ASP.Net webpage is taking a long time to load (maybe due to a slow database call or whatever), and the user decides they want to navigate to a different page because they are tired of waiting, THEY CAN'T! The ASP.Net session lock forces the new page request to wait until the original request has finished its painfully slow load. Arrrgh.

任何时候 UpdatePanel 加载缓慢，并且用户决定在 UpdatePanel 完成更新之前导航到不同的页面......他们不能！ASP.net 会话锁强制新页面请求等待原始请求完成其痛苦的缓慢加载.双重啊！

Anytime an UpdatePanel is loading slowly, and the user decides to navigate to a different page before the UpdatePanel has finished updating... THEY CAN'T! The ASP.net session lock forces the new page request to wait until the original request has finished its painfully slow load. Double Arrrgh!

那么有哪些选择呢?到目前为止，我想出了:

So what are the options? So far I have come up with:

• 实现 ASP.Net 支持的自定义 SessionStateDataStore.我还没有找到太多可以复制的，而且看起来风险很高，而且很容易搞砸.
• 跟踪所有正在进行的请求，如果请求来自同一用户，则取消原始请求.看起来有点极端，但它会起作用(我认为).
• 不要使用会话！当我需要用户的某种状态时，我可以只使用 Cache 和经过身份验证的用户名上的关键项目，或类似的东西.再次看起来有点极端.

我真的不敢相信 ASP.Net 微软团队会在 4.0 版本的框架中留下如此巨大的性能瓶颈！我错过了一些明显的东西吗?为 Session 使用 ThreadSafe 集合有多难?

I really can't believe that the ASP.Net Microsoft team would have left such a huge performance bottleneck in the framework at version 4.0! Am I missing something obvious? How hard would it be to use a ThreadSafe collection for the Session?

推荐答案

好的，非常感谢 Joel Muller 的所有意见.我的最终解决方案是使用这篇 MSDN 文章末尾详述的 Custom SessionStateModule:

OK, so big Props to Joel Muller for all his input. My ultimate solution was to use the Custom SessionStateModule detailed at the end of this MSDN article:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

这是:

• 实施起来非常快(实际上似乎比走供应商路线更容易)
• 使用了很多开箱即用的标准 ASP.Net 会话处理(通过 SessionStateUtility 类)

这对我们的应用程序快速"的感觉产生了巨大的影响.我仍然无法相信 ASP.Net Session 的自定义实现会锁定整个请求的会话.这给网站增加了如此大量的缓慢.从我必须进行的在线研究(以及与几位真正有经验的 ASP.Net 开发人员的对话)来看，很多人都遇到过这个问题，但很少有人深入了解原因.也许我会写一封信给 Scott Gu...

This has made a HUGE difference to the feeling of "snapiness" to our application. I still can't believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu...

我希望这对那里的一些人有所帮助！

I hope this helps a few people out there!

这篇关于我刚刚发现为什么所有的 ASP.Net 网站都很慢，我正在努力想办法解决这个问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！