会话的请求队列限制已超过。

28

我在ASP.NET应用程序中遇到了这个错误,使用的是NET 4.7.1。

会话的请求队列限制已超过。

完整内容:

System.Web.HttpException (0x80004005): The request queue limit of the session is exceeded.
at System.Web.SessionState.SessionStateModule.QueueRef()
at System.Web.SessionState.SessionStateModule.PollLockedSession()
at System.Web.SessionState.SessionStateModule.GetSessionStateItem()
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)

有什么建议吗?

3个回答

35

.NET 4.7的默认行为已更改。重新定位指南建议

为了恢复旧行为,您可以将以下设置添加到您的web.config文件中以选择退出新行为。

<appSettings>
  <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>

更改行为的澄清:

在.NET Framework 4.6.2及更早版本中,ASP.NET使用相同的Sessionid顺序执行请求,并且ASP.NET默认始终通过cookie发出Sessionid。如果页面响应时间很长,仅通过浏览器上的F5键就会显着降低服务器性能。在修复中,我们添加了一个计数器来跟踪排队的请求,并在超过指定限制时终止请求。默认值为50。如果达到限制,将在事件日志中记录警告,并可能在IIS日志中记录HTTP 500响应。

此外,在此处解决:https://knowledgebase.progress.com/articles/Article/The-request-queue-limit-of-the-session-is-exceeded-in-sitefinity-11-2


2
原因是什么?没有恢复旧行为的解决方案吗?问题不在于4.5,而是在于4.7.1... 是4.7.1中的错误吗?解决方法是恢复旧行为。 - Kiquenet
2
是的,这可能是4.7.1版本中的一个错误,因为它是由于最近在4.7版本中的更改引起的。我不知道具体原因,但微软文档也提到了这种重新定位类型的解决方案。有关从4.5.2升级到4.7.1的所有建议更改都记录在此处:https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.5.2-4.7.1。 - Mart Wienk
2
为什么页面响应时间很长?https://world.episerver.com/blogs/mahdi-shahbazi/dates/2018/10/the-request-queue-limit-of-the-session-is-exceeded--system-web-httpexception-at-system-web-sessionstate-sessionstatemodule-queueref/ 解决方法: <add key="aspnet:AllowConcurrentRequestsPerSession" value="true" /> - Kiquenet
我这里有些困惑,如果我的应用程序运行在 .NET Framework 4.7.1 上并出现错误:The request queue limit of the session is exceeded,那么 aspnet:RequestQueueLimitPerSession 的值应该是 25 还是 2147483647? - Arjun
这个错误也可能发生在 .Net 4.6.2 中,有什么解决方法吗? - Igor
2
这不是一个错误,而是一个特性。它有助于防止慢端点的过载。它为每个用户会话和资源设置了50个排队请求的限制。请记住,仅通过查询字符串参数不同的请求被视为相同的资源。如果您的旧应用程序具有像image.aspx?id=1234这样的链接,并且在页面上多次调用该链接,可能会遇到此问题。MVC端点往往避免了这个问题,因为每个资源的URI是唯一的(/image/1234)。 - Neil Laslett

3
有时候这个错误是由服务器端太多的重定向导致的,在调查后我发现实际上是由于ActionsFilter将用户重定向到相同的操作引起的,解决了这个问题之后就没有再出现过。我认为如果您调查IIS日志,您更有可能找到相同的问题。
PS. 对于这种情况,设置RequestQueueLimitPerSession不会解决问题。
复现步骤:在IE 11中打开指定路径并按F5键60秒。它会生成大量请求到这个路径,如果我们看一下iis,我们会发现一些带有win-32状态=64的请求。 enter image description here 仔细分析IIS日志将为您提供关于此请求/用户代理/所有访问路径/请求状态等性质的大量信息。

有什么解决方案吗?如何避免DDoS攻击? - Kiquenet
您可以按IP地址封锁用户一段特定的时间范围。 - BASKA

3

我在我的MVC应用程序(.NET版本4.7.2)中遇到了同样的错误,当活动量异常高时会出现。通过在应用程序的数据库中添加必要的表索引来解决这个问题。在我的情况下,解决方案不是调整"aspnet:RequestQueueLimitPerSession"设置,而是解决导致会话请求超过默认限制的数据库性能潜在问题。


1
添加必要的表索引?您是否使用任何工具来获取推荐的索引? - Kiquenet
4
我使用SQL Server Management Studio中提供的Activity Monitor工具来识别“最近昂贵的查询”。我按“每分钟执行次数”和“CPU(ms / sec)”对结果进行排序,以找到引起问题的存储过程。接下来,我在SQL Server Management Studio中执行了该存储过程,并选择了“包括实际执行计划”选项,SQL Server为我识别了缺失的索引。 希望这可以帮助您。如果您需要更多信息,请告诉我。 - kyletme

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接