记录 – Windows中的Nginx $request_time和$upstream_response_t

发布时间：2020-12-13 22:39:47 所属栏目：Windows 来源：网络整理

导读：我在 Windows上运行Nginx的访问日志中遇到了一些奇怪的现象.我在我的访问日志中包含$request_time以及$upstream_response_time(将Django作为fcgi上游运行).我的理解是日志应该以毫秒为单位表示请求时间,但它的输出如下所示： ip|date|request_time|upstream_

我在 Windows上运行Nginx的访问日志中遇到了一些奇怪的现象.我在我的访问日志中包含$request_time以及$upstream_response_time(将Django作为fcgi上游运行).我的理解是日志应该以毫秒为单位表示请求时间,但它的输出如下所示：

ip|date|request_time|upstream_response_time
xx.xx.xx.xxx|[29/Jan/2013:15:29:57 -0600]|605590388736.19374237|0.141
xx.xx.xx.xxx|[29/Jan/2013:15:30:39 -0600]|670014898176.19374237|0.156

任何想法是什么巨大的数字！？

这是完整的日志格式(我在上面的示例中删除了几个列)

log_format  main  '$remote_addr|$time_local]|$request|$request_time|$upstream_response_time|'
                  '$status|$body_bytes_sent|$http_referer|'
                  '$http_user_agent';

使用管道分隔符.

解决方法

所以你在这里建议的答案是：

当您向服务器(nginx上游)发出GET请求时,$request_time结果具有正常和可接受的值.之所以会发生这种情况,是因为您的上游服务器不参与其中,即使这样做也能使其正常运行.

在执行POST请求时问题就开始了.根据$request_time变量的nginx doc值(仅在日志记录时可用)将在所有数据已发送且连接已关闭时计算(由所有上游和代理也).然后只有信息附加到日志.

那么如何检查一切是否正确？
首先对服务器执行GET请求并查看日志文件.注意完成调用并将日志信息添加到文件中需要多长时间 – 它应该是真正的价值.
接下来对服务器发出POST请求并再次查看日志文件.在这里,您可能会看到日志根本没有出现或经过很长时间.

这是什么意思？检查你的nginx conf和你的上游conf,因为某个地方可能是一个没有关闭连接的地方,只是挂在空中.这些连接可以在您的操作系统或上游服务器之后更新,但毕竟它可能会导致一些问题,而不仅仅是奇怪的$request_time值.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!