（TTFB）一些特定的请求所花的时间比执行实际请求所花的时间长

Question

标题可能看起来有点模糊，这是我的问题的详细信息。我有一个Web应用程序，它由3个层组成：一个有角度的前端项目，.NET Core api网关中间件项目和作为后端层的.NET项目。所有这三个项目都是相互独立的，并且运行良好。我的问题是，在我项目中拥有的大多数端点中，请求均按预期的毫秒级完成并返回数据，但是其中一些似乎等待了不可辩驳的时间，并且这是随机发生的。下面显示了上述GET请求的Chrome响应计时输出。

Chrome计时详细信息

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

堆叠跟踪输出

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

Api网关日志

总而言之，响应在我的api网关项目（.NET Core）中等待，我不知道为什么这在某些端点上随机发生。最后，我只是将请求发送到我的api网关项目中的相关端点，而没有进行任何操作。要了解并解决此问题，请先感谢您的帮助和建议。

Answer 1

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

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

  

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

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

Answer 2

如果应用程序离线，则将需要几秒钟的时间才能再次在线，这就是大多数情况下TTFB（到第一个缓冲区的时间）花费大量时间进行响应的原因。

另一种可能的情况；如果该请求用于获取图像，则可能是图像的大小。

最后但并非最不重要的一点是，您可以尝试减少服务器后端的工作量。

此帖子有相同的问题：How can I reduce the waiting (ttfb) time