(TTFB) 某些特定请求的执行时间比执行实际请求的时间长答案

【问题标题】：(TTFB) Some specific requests takes longer than it takes to execute the actual request(TTFB) 某些特定请求的执行时间比执行实际请求的时间长
【发布时间】：2019-01-11 08:13:51
【问题描述】：

标题可能有点模糊，这是我的问题的详细信息。我有一个由 3 层组成的 Web 应用程序，一个 Angular 前端项目、.NET Core api 网关中间件项目和作为后端层的 .NET 项目。这三个项目都是相互独立的并且工作正常。我的问题是，在我项目中的大多数端点上，请求都按预期以毫秒级别完成并返回数据，但其中一些似乎等待了无可辩驳的时间，而且这种情况是随机发生的。上述 GET 请求的 Chrome 响应时间输出如下所示。

Chrome 计时详情

正如您在上面看到的，这里花费的大部分时间都是等待。另外，我在stackify中跟踪了这种类型的请求，并且似乎该请求在后端项目中以ms级别完成。 Stackify 输出如下所示。

Stackify 跟踪输出

如上所示，我的后端响应最长耗时 835 毫秒，并返回了适当的响应。最后，从我的 gateway 在 Kibana 中生成的日志中，我有以下计时日志，该日志也显示请求花费了大约 8 秒。

API 网关日志

总结一下这个问题，我的 api 网关项目 (.NET Core) 等待响应，我不知道为什么这会在某些端点随机发生。最后，我只是向我的 api 网关项目中的相关端点发送请求，没有进行任何操作。为了解和解决此问题，请提前提供任何帮助和建议。

【问题讨论】：

标签： .net angular iis asp.net-core

【解决方案1】：

正如this 博文中所述，事实证明，第一个请求的延迟可能是由注册为Singleton 的服务引起的。为了解决这个问题，链接的博客文章建议创建一个热身启动功能是解决这个问题的方法，而我主要注册了我的服务Transient。

此外，我在前面提到的博客文章中的 cmets 中观察到 this 有用的博客文章，它提出了如下解决方案。

我能找到的唯一可靠的解决方案不是很科学：部署后，只需向 api 的端点发送几个预热请求。

如上所述，我的解决方案是将实际的 http 请求发送到我的 api 项目。希望这可以帮助那些和我一样遇到同样问题的人。

【讨论】：

【解决方案2】：

如果应用下线，再次上线需要几秒钟，在大多数情况下，这就是为什么 TTFB（第一次缓冲时间）需要很长时间才能响应的原因。

另一种可能的情况；如果请求是用来获取图片的，原因可能是图片的大小。

最后但同样重要的是，您可以尝试减少服务器后端的工作量。

这篇文章有同样的问题：How can I reduce the waiting (ttfb) time

【讨论】：

感谢您的回答。但是为了演示问题，图像尺寸很小。我会检查你指出的内容。
顺便说一句，如果原因是由于离线；您可以使用网络服务来让您的应用程序保持活力，例如“正常运行时间机器人”；它会频繁 ping 应用程序以检查其可用性，并且您可以管理大约 5-10 分钟的频率，这足以让您的应用程序保持活力。
另外，尝试ping服务器很长时间，它似乎一直在运行。但类似地，一些 ping 响应需要 6 毫秒，而大多数 ping 在 1 毫秒内返回。