相关疑难解决方法(0)

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

如果这对你造成影响,就像我一开始对你而言,这基本上意味着以下几点:

• 任何时候ASP.Net网页需要很长时间才能加载(可能是由于数据库调用速度慢等),并且用户决定他们想要导航到另一个页面,因为他们厌倦了等待,他们不能!ASP.Net会话锁强制新页面请求等待,直到原始请求完成其缓慢的负载.Arrrgh.

• 任何时候UpdatePanel加载缓慢,并且用户决定在UpdatePanel完成更新之前导航到另一个页面......他们不能!ASP.net会话锁强制新页面请求等待原始请求完成其缓慢的负载.双Arrrgh!

那有什么选择呢？到目前为止,我想出了:

• 实现ASP.Net支持的自定义SessionStateDataStore.我没有找到太多的副本,它似乎有点高风险,容易搞砸.
• 跟踪正在进行的所有请求,如果来自同一用户的请求,则取消原始请求.看起来有点极端,但它会起作用(我认为).
• 不要使用Session!当我需要用户的某种状态时,我可以使用Cache代替,以及经过身份验证的用户名上的关键项,或者其他类似的东西.再次看起来有点极端.

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

我正在研究一个大型C#/ .NET 3.5系统的性能问题,它表现出性能下降,因为发出请求的用户数量每秒可扩展到40-50个不同的用户请求.

请求持续时间显着增加,而CPU和I/O负载似乎保持不变.这让我相信,我们的系统中使用c#lock() {...}语句保护的共享对象如何影响并发访问性能可能会遇到问题.具体来说,我怀疑在关键部分保护的常用共享数据上会发生某种程度的锁定会话(因为它是读/写).

有没有人有关于如何实际诊断是否存在锁定康复问题的建议？或者是否有任何类型的锁争用导致请求时间过长？