为什么页面处理的 AspNetSessionData 阶段将我的页面延迟了 20+秒？
我有一个 Web 应用程序，它使用 ASP.NET 和“InProc”会话处理。通常情况下，一切正常，但每天运行数百个请求所需的时间比正常情况要长得多。在 IIS 日志中，我可以看到这些页面（通常需要 2-5 秒才能运行）运行了 20 秒以上。
我在详细模式下启用了失败请求跟踪，发现延迟发生在 AspNetSessionData 部分。在下面所示的示例中，AspNetSessionDataBegin 和 AspNetSessionDataEnd 之间有 39 秒的间隙。
我不知道下一步该做什么。我找不到任何导致这种延迟的原因，也找不到更多可以启用的日志记录功能来告诉我这里发生了什么。有谁知道为什么会发生这种情况，或者对我可以采取其他步骤来查找问题有任何建议吗？
我的应用程序通常在会话中为每个用户存储 1-5MB，大部分是用于搜索的缓存数据。服务器有足够的可用内存，并且只运行大约 50 个用户。
I have a web application that uses ASP.NET with "InProc" session handling. Normally, everything works fine, but a few hundred requests each day take significantly longer to run than normal. In the IIS logs, I can see that these pages (which usually require 2-5 seconds to run) are running for 20+ seconds.
I enabled Failed Request Tracing in Verbose mode, and found that the delay is happening in the AspNetSessionData section. In the example shown below, there was a 39-second gap between AspNetSessionDataBegin and AspNetSessionDataEnd.
I'm not sure what to do next. I can't find any reason for this delay, and I can't find any more logging features that could be enabled to tell me what's happening here. Does anyone know why this is happening, or have any suggestions for additional steps I can take to find the problem?
My app usually stores 1-5MB in session for each user, mostly cached data for searches. The server has plenty of available memory, and only runs about 50 users.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能是由会话状态的锁争用引起的。查看 MSDN 的最后一段 ASP.NET 会话状态概述 。另请参阅 K 。 Scott Allen 关于这个主题的有用帖子。
如果页面使用 EnableSessionState="True" 注释（或继承 web.config 默认值），则该页面的所有请求都将获取会话状态的写锁。使用会话状态的所有其他请求（即使它们没有获取写锁）都会被阻止，直到该请求完成。
如果页面使用 EnableSessionState="ReadOnly" 进行注释，则该页面将不会获取写锁定，因此不会阻止其他请求。 （尽管它可能会被持有写锁的另一个请求阻止。）
为了消除这种锁争用，您可能需要围绕 HttpContext.Cache 对象或静态 弱引用。后者可能更有效。 （请参阅 Richard Kiessig 的 超快速 ASP.NET 第 118-122 页.)
It could be caused by lock contention for the session state. Take a look at the last paragraph of MSDN's ASP.NET Session State Overview. See also K. Scott Allen's helpful post on this subject.
If a page is annotated with EnableSessionState="True" (or inherits the web.config default), then all requests for that page will acquire a write lock on the session state. All other requests that use session state -- even if they do not acquire a write lock -- are blocked until that request finishes.
If a page is annotated with EnableSessionState="ReadOnly", then the page will not acquire a write lock and so will not block other requests. (Though it may be blocked by another request holding the write lock.)
To eliminate this lock contention, you may want to implement your own [finer grained] locking around the HttpContext.Cache object or static WeakReferences. The latter is probably more efficient. (See pp. 118-122 of Ultra-Fast ASP.NET by Richard Kiessig.)
您的运行可能会达到应用程序池允许消耗的最大内存量，这会导致应用程序池重新启动（这将导致您在访问会话时看到的延迟）。服务器上的内存量不会影响 ASP.NET 可以使用的内存量，这是在 machine.config 中的 memoryLimit 属性中控制的，在 IIS 6.0 中更高版本的 IIS 本身中使用“最大使用内存”属性进行控制。除此之外，您是否考虑过每个用户使用 5 MB 会话内存的替代方案？这根本无法很好地扩展，并且在负载下可能会导致很多问题。缓存可能是更有效的解决方案吗？搜索是否需要花费很长时间，以至于您需要执行此操作，是否可以优化 SQL/数据库设置以加快查询速度？
There is chance your are running up against the maximum amount of memory that Application Pool is allowed to consume, which causes a restart of the Application Pool (which would account for the delay you are seeing in accessing the session). The amount of memory on the server doesn't impact the amount of memory ASP.NET can use, this is controlled in the machine.config in the memoryLimit property and in IIS 6.0 later in IIS itself using the "Maximum memory used" property. Beyond that, have you considered alternatives to each user using 5 MB of session memory? This will not scale well at all and can cause a lot of issues while under load. Might caching be a more effective solution? Do the searches take so long that you need to do this, could the SQL/Database Setup be optimized to speed up your queries?