☰

为什么 $request_time 有时比 $upstream_response_time 大得多？

tag-icon • tag-icon nginx http performance-monitoring
为什么 $request_time 有时比 $upstream_response_time 大得多？

我有一个 HTTPS 网站，有时对于相同的客户端，$request_time 是 $upstream_response_time 的 10 倍，甚至是 100 倍。我理解这两个时间之间的区别：$request_time 是收到的第一个字节和发送的最后一个字节之间的持续时间。

一些用户告诉我他们遇到了连接超时，所以我认为这些长的 $request_time 是真正的问题。

这些较长的 $request_time 发生在 GET 请求中（典型请求大小：185 字节）。上游是一个 fastcgi 进程。我想知道在哪种情况下 $request_time 可能太高：

  1. 没有 fastcgi 工作者正在接受连接，$request_time 包含 fastcgi 进程的“等待时间”
  2. 响应不正确（内容长度错误、分块响应）且客户端正在等待未到达的数据
  3. SSL 证书：客户端获取我们的 SSL 证书，请求 OCSP 并完成 SSL 连接。

我想知道哪些选项实际上是可行的，以及如何找出实际创建长 $request_time 的原因。

答案1

OSCP 时常是一个问题，但我会在超时/不可用的 fastcgi-workers 方向进行更多调查。这是一个真正的 heisenbug 吗？还是当它发生时，它只发生在不同的用户身上？您是否有基于 http 的监控（例如通过 Nagios、Selenium 等发出真正的 GET 请求，而不仅仅是端口 80/443 - 检查）

调试步骤：

  • 复制您的服务器{} - 阻止并使用不同的端口（仅用于调试）
  • 调整非常短的代理读取/发送超时
  • 当用户遇到等待时间并尝试捕捉一些超​​时时，浏览您的调试服务器
  • 为你的日志文件构建一个解析器来捕获和分析长期运行的日志文件

相关内容