ASP.NET 会话性能
我的 ASP.NET 应用程序遇到性能问题。有时客户端需要 30-40 秒来执行命令，而有时则需要 3-4 秒。我尝试了 SQL Profiler，没有发现任何问题。在客户尝试的相同场景下，我无法在我这边复制该问题。
我认为这可能与我正在使用的会话变量有关。我使用了很多它们来在页面内传递信息。不过我不清除它们。
如果我清除它们会有帮助吗？如果是这样，这会影响其他用户吗？还是仅对该用户清楚？
任何帮助表示赞赏。
I'm experiencing performance issues on my asp.net application. Sometimes it would take the client 30-40 seconds to execute a command, where as in sometimes it would take 3-4 seconds. I tried SQL Profiler and I don't see any problems. I was not able to replicate the issue on my side, under the same scenario when the client was trying.
I'm thinking that it might to do with session variables i'm using. I am using a lot of them to pass information within the page. However I Do not clear them.
If I clear them would it help? and if So Would this affect other users. Or does it only clear for that user?
Any help is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
基于 SQL Server 的会话存储的 .NET 2.0 实现中的存储过程之一存在记录锁定问题。看来 MS 在 .NET 4.0 版本中合并了该修复程序。
看看这里：
http://sanjevsharma.blogspot.com/2008/03 /improving-aspnet-session-state-database.html
我 99% 确定您可以运行 4.0 版本的 aspnet_regsql -ssadd 并且仍然可以针对它运行 ASP.NET 2.0。我记得对 2.0 与 4.0 SQL 脚本进行了比较，上面的修复是唯一真正的区别。 MS 的修复实现比上面的链接好一点（并且明显基于）。
There was a record locking problem in one of the stored procedures in the .NET 2.0 implementation of SQL Server-based session storage. It looks like MS incorporated the fix in the .NET 4.0 release.
Take a look here:
http://sanjevsharma.blogspot.com/2008/03/improving-aspnet-session-state-database.html
I'm 99% sure you can run the 4.0 version of aspnet_regsql -ssadd and still run ASP.NET 2.0 against it. I remember doing a diff of the 2.0 vs. 4.0 SQL script and the above fix was the only real difference. MS' implementation of the fix was a little nicer than (and clearly based on) the link above.
会话和会话变量是特定于用户的，因此清除它们不会影响其他用户。
保持轻松的会话肯定有助于提高性能。
Session and so session variables are user specific so clearing them will not affect other users.
keeping your session light will certainly help improving performance.
建议 ASP.NET 会话在正常操作过程中不会影响 SQL Server 往返时间。假设没有在与数据层相关的会话中存储任何内容（即静态 SqlConnection 对象），
如果您看到时间较长（30-40 秒），请尝试确定性能是否逐渐变慢，或者您的 SQL Server 往返时间是否已缩短是零星的。
考虑实施日志记录来帮助确定模式。首先写入磁盘，每天/每小时写入一个文件（视情况而定）。
一小时/天/周后，打开日志查找“Roundtrip”，也许编写一个程序来为您解析这些日志。
Suggest that ASP.NET Session wouldn't impact your SQL Server roundtrip times in normal course of operating. Assuming nothing is being stored in session related to your data layer (i.e. static SqlConnection objects)
If you're seeing those long times (30-40 seconds), try to determine if performance is a gradual slowdown, or whether your SQL Server roundtrip times are sporradic.
Consider implementing logging to help determine a pattern. Start by writing to disk, one file per day/hour as you see appropriate.
After an hour/day/week, open the logs to look for "Roundtrip", and perhaps write a program to parse these logs for you.
如果问题似乎不是出在您的数据库上，您可以尝试分析您的 Web 应用程序并查看瓶颈所在。很难重现您在生产中看到的变量问题（4-40 秒延迟），但是发生了多少方法调用以及哪些方法调用消耗最多执行时间的结果可能会提供提示。
What Are Some Good .NET Profilers? 中提到了一些内容，
我个人认为EQATEC 分析仪的忠实粉丝。
If the problem doesn't seem to be your database, you could try profiling your web app and see where the bottlenecks are. It's difficult to reproduce variable problems like you're seeing on production (4-40 second delays), but the results of how many method calls are happening and which ones consume the most execution time might provide a hint.
Some are mentioned in What Are Some Good .NET Profilers?
Personally I'm a big fan of the EQATEC profiler.
如果您有这种规模的变化，您很可能正在考虑某种锁定或争用问题。根据时间安排以及您分析时发生的其他情况，您可能不会看到 SQL 锁定问题（如果确实如此）。尝试监视 perfmon 中的锁定指标，看看是否有任何可疑之处，并考虑一下系统中还有哪些因素可能导致任何类型的锁定或延迟等待时间。
If you've got variability on that scale, you could very well be looking at some sort of locking or contention issue. Depending on timing, and what else is going on when you profile, you might not see a SQL locking issue if that's what it is. Try monitoring lock metrics in perfmon to see if there's anything suspicious there, and give some thought to what else in the system could be causing any sort of locking or latency wait time.
您是否尝试过启用 ASP.NET 跟踪日志记录并查看调用堆栈中的加载时间？我经常使用它来诊断 ASP.NET 性能瓶颈。如果您不熟悉trace.axd，您可以通过配置文件启用它。
启用此配置设置将允许您浏览到站点根目录下的trace.axd 并详细查看最近10 笔交易。您可以通过该跟踪元素启用更大的结果集、滚动结果集以及许多其他漂亮的跟踪选项。
Have you tried enabling ASP.NET trace logging and viewing the load times in the call stack? I've used this quite a bit to diagnose bottlenecking in ASP.NET performance. If you're unfamiliar with trace.axd, you can enable it via your configuration file
Enabling this configuration setting will allow you to browse to trace.axd at the root of your site and view the last 10 transactions in detail. You can enable a larger result set, rolling result sets, and a bunch of other nifty tracing options through that trace element.