为什么$ request_time有时比$ upstream_response_time大很多?

我有一个HTTPS网站,有时,对于相同的客户端,$ request_time是$ upstream_response_time的10倍,甚至100倍。 我理解2次之间的差异:$ request_time是接收到的第一个字节和发送的最后一个字节之间的持续时间。

有些用户告诉我,他们经历了连接超时,所以我认为这些很长的$ request_time是真正的问题。

这些很长的$ request_time发生GET请求(典型的请求大小:185字节)。 上游是一个fastcgi过程。 我想知道在什么情况下$ request_time可能太高:

  1. 没有fastcgi工作人员正在接受连接,$ request_time包含fastcgi进程的“等待时间”
  2. 响应不正确(错误的内容长度,分块的响应),客户端正在等待未来的数据
  3. SSL证书:客户端获得我们的SSL证书,请求OCSP并完成SSL连接。

我不知道哪些选项实际上是可能的,我怎么会找出什么是实际上创build长$ request_time。

OSCP是一个问题,但在那里,但我会调查更多的超时/不可用fastcgi工人的方向。 这是一个真正的heisenbug还是发生,当它发生,不同的用户? 你有基于http的监控(例如,通过Nagios,Selenium等真正的GET请求,而不仅仅是端口80/443 – 检查)

debugging步骤:

  • 复制您的服务器{} – 阻止并使用不同的端口(仅用于debugging)
  • 调整非常短的代理读取/发送 – * – 超时
  • 浏览你的debugging服务器,当用户体验等待时间,并尝试捕捉一些超​​时
  • 为你的日志文件build立一个parsing器来捕捉和分析长期运行者