摘要:搜索,出现的内容基本上是和的区别。这些博文中提到的定义,与上面理解的也是一样的。除了知道初始化为当前值,暂无对问题解惑的有用信息。根据与的关系,这个肯定值得看看。
转载请注明文章出处:https://tlanyan.me/upstream_r...
前几日为了查看FPM的性能,在Nginx的配置里增加FPM响应时间的header:
http { ... server { ... location ~ .php$ { ... add_header X-Upstream-Time $upstream_response_time; } } }
今天闲来查看网页的响应头,发现值与预期的不一致:
要说153毫秒我是相信的,那么数值的单位是纳秒。但这不符合常理:1. 印象中upstream_response_time的单位是毫秒;2. 如果单位是纳秒,就不应该有小数点,精度没这么高(从L1缓存取个值就要0.5~1纳秒,从寄存器取值差不多也要个0.2纳秒)。
难道是我对upstream_response_time理解错了?翻看Nginx官方文档,对该变量的解释是:
$upstream_response_time keeps time spent on receiving the response from the upstream server; the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the $upstream_addr variable.
翻译过来:upstream_response_time是与上游(FPM)建立连接开始到接收完内容花费的时间,单位为毫秒。所以理解没有错,那么错在什么地方呢?
所以Nginx版本的bug?试了另外几个版本,情况一致。
搜索"nginx upstream_response_time",出现的内容基本上是request_time和upstream_response_time的区别。这些博文中提到的定义,与上面理解的也是一样的。
再仔细琢磨这个值,发现怎么有点像时间戳啊?!马上用PHP验证一下:
php -a echo date("Y-m-d H:i:s", 1535347303.280);
PHP shell输出"2018-08-27 13:21:43",证明其就是时间戳。
没给预期的上游处理时间,给一个时间戳算什么事?接续Google "nginx upstream_response_time timestamp",结果列表第一个标题似乎就是我的疑问:"Re: nginx report a timestamp on upstream_response_time"。点进去一看,是官方邮件组中某个讨论的回复自动贴在了官方论坛上。除了知道upstream_response_time初始化为当前值(ngx_timeofday()),暂无对问题解惑的有用信息。
继续往下翻,马上就看到了有人在OpenResty提出的issue:[bug] the upstream-response-time value is wrong #206。根据Nginx与OpenResty的关系,这个issue肯定值得看看。章亦春大佬对该issue的回复(也是对upstream_response_time是时间戳的解答)是:
所以upstream_response_time在header中不准确的原因是:其值在log阶段(NGX_HTTP_LOG_PHASE)才会正确生成,发送响应头处于内容生产阶段(NGX_HTTP_CONTENT_PHASE),期间获取到的值是初始化的时间戳,符合预期。
要正确打印其值,可在日志格式中声明:
http { ... log_format main "$remote_addr - $remote_user [$time_local] "$request" " "$status $body_bytes_sent "$http_referer" " ""$http_user_agent" "$http_x_forwarded_for" "$request_time" "$upstream_response_time""; }
重新加载Nginx配置,刷新网页然后查看日志,每一行最后一列就是我们想要的upstream_response_time:
xxxx - - [27/Aug/2018:14:20:13 +0800] "GET xxx HTTP/1.1" 200 7659 "xxx" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Mobile/14D27 MicroMessenger/6.5.5 NetType/WIFI Language/zh_CN" "-" "0.000" "-" xxx - - [27/Aug/2018:14:20:16 +0800] "GET xxx HTTP/1.1" 200 423 "xxx" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Mobile/14D27 MicroMessenger/6.5.5 NetType/WIFI Language/zh_CN" "-" "0.000" "-" xxx - - [27/Aug/2018:14:20:29 +0800] "GET / HTTP/1.0" 200 6775 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36" "-" "0.185" "0.010"参考
http://nginx.org/en/docs/http...
https://www.nginx.com/blog/us...
https://forum.nginx.org/read....
https://github.com/openresty/...
https://blog.csdn.net/qinyush...
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/40079.html
摘要:最终获得一个链接,里面有这样的描述如何在阿里云负载均衡上启用支持无需配置,当选用监听时,默认支持无加密版本协议协议当选择监听时,默认支持加密版本的协议协议。详细参见如何使用负载均衡性能保障型实例。 Websocket是HTML5之后的一个新事物,可以方便的实现客户端到服务端的长会话,特别适合用于客户端需要接收服务端推送的场景。例如在线客服聊天,提醒推送等等。改变了以往客户端只能通过轮询...
摘要:我会写一些是后端技术前端工程相关的文章,偶尔会有一些大数据相关,也会推荐一些好玩的东西。 showImg(https://segmentfault.com/img/remote/1460000006767498); Nginx作为所有HTTP请求的入口,是非常重要的一层。本文主要介绍如何利用 Nginx日志实时监控每个业务的请求异常。 这篇文章基于我之前的的一篇 《基于Lua+Kaf...
摘要:前言业务野蛮生长时期,作为一枚,有运营过比较长的一段时间。根据该是否和匹配绝对是否对前端返回。开发人力不足以重构这个接口,为了不影响调用成功率,想都设置为返回成功之类的状态码记录慢日志为提高接口的运营质量,同时也方便定位一些奇怪的问题。 前言 业务野蛮生长时期,作为一枚op,有运营过nginx比较长的一段时间。期间遇到些小问题,这里简单做个总结记录,会不定时更新: 开始扯淡 pr...
摘要:进程数的配置会奏效会自动增加数但是性能提升效果并不明显然而的并没奏效,仍然只有一个通过手动增加配置发现有所提升但效果很不明显。于是我更改了的配置改为再次结果能达到左右差不多翻倍了结论性能问题并不那么容易解决需要耐心的排查原因 一直知道nginx本身能进行负载均衡,但没有测试过,今天实验了下,以下是笔记记录 showImg(https://segmentfault.com/img/rem...
阅读 2484·2023-04-25 22:09
阅读 988·2021-11-17 17:01
阅读 1442·2021-09-04 16:45
阅读 2566·2021-08-03 14:02
阅读 755·2019-08-29 17:11
阅读 3232·2019-08-29 12:23
阅读 1062·2019-08-29 11:10
阅读 3255·2019-08-26 13:48