AspNetCore (Kestrel) 请求超时答案

【问题标题】：AspNetCore (Kestrel) request timed outAspNetCore (Kestrel) 请求超时
【发布时间】：2018-03-08 07:37:04
【问题描述】：

我有以下设置：在应用程序负载均衡器 (AWS) 后面的几个 linux 容器（基于 aspnetcore 2.0.5 构建）中运行的 web api

使用 HttpClient 向此 api 发出请求的客户端。客户端正在并行运行多个任务的调用。如果并行任务的数量增加，则 api 开始抛出异常并显示“请求超时”消息。

调用栈是：

在 Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.PipeCompletion.ThrowFailed() 在 Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.GetResult(ReadResult& 结果）在 Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.IReadableBufferAwaiter.GetResult() 在 Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.ReadableBufferAwaitable.GetResult() 在 Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.d__24.MoveNext() --- 从先前抛出异常的位置结束堆栈跟踪 --- 在 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 在 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务任务）在 Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Frame`1.d__2.MoveNext()

什么会导致这个错误，谁在设置超时，我该如何进一步调查？

编辑：如果我尝试 fiddler 捕获失败的请求，则不再抛出错误（也许 fiddler 以较低的并行度打开连接）。

【问题讨论】：

你试过增加httpClient.TimeOut吗？此外，使用特定端点或所有类型的请求是否存在此问题？
我在 httpClient.Timeout 上尝试了不同的设置（以及关闭或保持连接打开的组合），但没有任何区别。失败的方法是执行一些冗长的文件系统操作。我创建了另一个只是等待（等待 Task.Delay() 一段时间，这个不会抛出相同的错误。
这些文件系统操作需要多长时间？如果超过几秒钟，这是一个设计缺陷。冗长的操作永远不应该由您的 Web 服务器处理，您应该启动某种类型的后台任务——在数据库中放置一个标志，将一条消息放在队列中，启动一个 Web 作业（因为您在 Azure 上），等等。如果持续时间少于 5 分钟，我个人会设置一个触发函数的队列，并利用函数应用程序的非常便宜的自动缩放消费计划。
糟糕，我猜 AWS 是亚马逊，而不是 Azure。尽管如此，基本概念仍然适用。
这是亚马逊对 EFS 文件系统的操作，在这个 FS 1 上操作通常需要大约 30 毫秒，但是当有很多请求进入时，时间会增加很多秒/请求。有解决方法，但我试图了解超时

标签： c# asp.net-core task kestrel-http-server

【解决方案1】：

一个可能的原因是由于 I/O 绑定操作，您阻塞了 asp.net 线程。从问题描述来看，您的服务器似乎正在处理某个点的请求。除此之外，它无法做到这一点。

我认为，如果您正确使用 Async/Await，那么您可以提供比当前限制更多的并发请求。

还可以通过配置检查是否可以增加 Asp.Net 线程的数量。传统的 Asp.Net 支持这一点。不确定 Asp.Net Core 是否有这个功能。

最后，既然您在云端运行，请检查升级服务器配置的可行性。可能升级的配置将帮助您处理更多的请求。显然这应该是最后的选择。首先专注于使用现有硬件提高应用程序的性能。

【讨论】：

我在整个 api 中使用 asycn/await 模式。我尝试使用线程数（现在这是在 libuv 选项中设置的），但没有区别。我会将机器升级到更强大的东西，看看这会有什么影响。我会回来详细说明的。
这似乎与线程数有关。只是升级服务器显示没有改善。我设法通过将 ThreadPool.MinThreads 设置为更高的值（在我的情况下为 800）来提高性能，并且还升级了 cotainer（是 linux）的“nofile”限制。我不确定，我希望这是请求超时消息背后的问题。
Min threads bad blogs.msdn.microsoft.com/vancem/2018/10/16/… 你解决这个问题了吗？