成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

Nginx的upstream_response_time

frontoldman / 2103人閱讀

摘要：搜索，出現(xiàn)的內(nèi)容基本上是和的區(qū)別。這些博文中提到的定義，與上面理解的也是一樣的。除了知道初始化為當(dāng)前值，暫無(wú)對(duì)問題解惑的有用信息。根據(jù)與的關(guān)系，這個(gè)肯定值得看看。

轉(zhuǎn)載請(qǐng)注明文章出處：https://tlanyan.me/upstream_r...

前幾日為了查看FPM的性能，在Nginx的配置里增加FPM響應(yīng)時(shí)間的header:

http {
  ...
  server {
    ...
    location ~ .php$ {
      ...
      add_header X-Upstream-Time $upstream_response_time;
    }
  }
}

今天閑來(lái)查看網(wǎng)頁(yè)的響應(yīng)頭，發(fā)現(xiàn)值與預(yù)期的不一致：

要說(shuō)153毫秒我是相信的，那么數(shù)值的單位是納秒。但這不符合常理：1. 印象中upstream_response_time的單位是毫秒；2. 如果單位是納秒，就不應(yīng)該有小數(shù)點(diǎn)，精度沒這么高（從L1緩存取個(gè)值就要0.5~1納秒，從寄存器取值差不多也要個(gè)0.2納秒）。

難道是我對(duì)upstream_response_time理解錯(cuò)了？翻看Nginx官方文檔，對(duì)該變量的解釋是：

$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.

翻譯過來(lái)：upstream_response_time是與上游（FPM）建立連接開始到接收完內(nèi)容花費(fèi)的時(shí)間，單位為毫秒。所以理解沒有錯(cuò)，那么錯(cuò)在什么地方呢？

所以Nginx版本的bug？試了另外幾個(gè)版本，情況一致。

搜索"nginx upstream_response_time"，出現(xiàn)的內(nèi)容基本上是request_time和upstream_response_time的區(qū)別。這些博文中提到的定義，與上面理解的也是一樣的。是官方提供付費(fèi)商業(yè)支持的站點(diǎn)，根據(jù)其站點(diǎn)上"Using NGINX Logging for Application Performance Monitoring"這篇博文，這個(gè)值是靠譜的（坑社區(qū)也就算了，不能坑給錢的上帝吧）。

再仔細(xì)琢磨這個(gè)值，發(fā)現(xiàn)怎么有點(diǎn)像時(shí)間戳啊？！馬上用PHP驗(yàn)證一下：

php -a
echo date("Y-m-d H:i:s", 1535347303.280);

PHP shell輸出"2018-08-27 13:21:43"，證明其就是時(shí)間戳。

沒給預(yù)期的上游處理時(shí)間，給一個(gè)時(shí)間戳算什么事？接續(xù)Google "nginx upstream_response_time timestamp"，結(jié)果列表第一個(gè)標(biāo)題似乎就是我的疑問："Re: nginx report a timestamp on upstream_response_time"。點(diǎn)進(jìn)去一看，是官方郵件組中某個(gè)討論的回復(fù)自動(dòng)貼在了官方論壇上。除了知道upstream_response_time初始化為當(dāng)前值（ngx_timeofday()），暫無(wú)對(duì)問題解惑的有用信息。

繼續(xù)往下翻，馬上就看到了有人在OpenResty提出的issue：[bug] the upstream-response-time value is wrong #206。根據(jù)Nginx與OpenResty的關(guān)系，這個(gè)issue肯定值得看看。章亦春大佬對(duì)該issue的回復(fù)（也是對(duì)upstream_response_time是時(shí)間戳的解答）是：

所以upstream_response_time在header中不準(zhǔn)確的原因是：其值在log階段(NGX_HTTP_LOG_PHASE)才會(huì)正確生成，發(fā)送響應(yīng)頭處于內(nèi)容生產(chǎn)階段(NGX_HTTP_CONTENT_PHASE)，期間獲取到的值是初始化的時(shí)間戳，符合預(yù)期。

要正確打印其值，可在日志格式中聲明：

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配置，刷新網(wǎng)頁(yè)然后查看日志，每一行最后一列就是我們想要的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...

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/40079.html

相關(guān)文章

  • 坑系列之阿里SLB上使用Webscoket

    摘要：最終獲得一個(gè)鏈接，里面有這樣的描述如何在阿里云負(fù)載均衡上啟用支持無(wú)需配置，當(dāng)選用監(jiān)聽時(shí)，默認(rèn)支持無(wú)加密版本協(xié)議協(xié)議當(dāng)選擇監(jiān)聽時(shí)，默認(rèn)支持加密版本的協(xié)議協(xié)議。詳細(xì)參見如何使用負(fù)載均衡性能保障型實(shí)例。 Websocket是HTML5之后的一個(gè)新事物，可以方便的實(shí)現(xiàn)客戶端到服務(wù)端的長(zhǎng)會(huì)話，特別適合用于客戶端需要接收服務(wù)端推送的場(chǎng)景。例如在線客服聊天，提醒推送等等。改變了以往客戶端只能通過輪詢...

    1treeS 評(píng)論0 收藏0

  • 基于Nginx日志的異常監(jiān)控策略

    摘要：我會(huì)寫一些是后端技術(shù)前端工程相關(guān)的文章，偶爾會(huì)有一些大數(shù)據(jù)相關(guān)，也會(huì)推薦一些好玩的東西。 showImg(https://segmentfault.com/img/remote/1460000006767498); Nginx作為所有HTTP請(qǐng)求的入口，是非常重要的一層。本文主要介紹如何利用 Nginx日志實(shí)時(shí)監(jiān)控每個(gè)業(yè)務(wù)的請(qǐng)求異常。? 這篇文章基于我之前的的一篇 《基于Lua+Kaf...

    meislzhua 評(píng)論0 收藏0

  • nginx線上運(yùn)營(yíng)tips總結(jié)

    摘要：前言業(yè)務(wù)野蠻生長(zhǎng)時(shí)期，作為一枚，有運(yùn)營(yíng)過比較長(zhǎng)的一段時(shí)間。根據(jù)該是否和匹配絕對(duì)是否對(duì)前端返回。開發(fā)人力不足以重構(gòu)這個(gè)接口，為了不影響調(diào)用成功率，想都設(shè)置為返回成功之類的狀態(tài)碼記錄慢日志為提高接口的運(yùn)營(yíng)質(zhì)量，同時(shí)也方便定位一些奇怪的問題。 前言 業(yè)務(wù)野蠻生長(zhǎng)時(shí)期，作為一枚op，有運(yùn)營(yíng)過nginx比較長(zhǎng)的一段時(shí)間。期間遇到些小問題，這里簡(jiǎn)單做個(gè)總結(jié)記錄,會(huì)不定時(shí)更新： 開始扯淡 pr...

    ZoomQuiet 評(píng)論0 收藏0

  • nginx+php-fpm負(fù)載均衡和性能測(cè)試

    摘要：進(jìn)程數(shù)的配置會(huì)奏效會(huì)自動(dòng)增加數(shù)但是性能提升效果并不明顯然而的并沒奏效，仍然只有一個(gè)通過手動(dòng)增加配置發(fā)現(xiàn)有所提升但效果很不明顯。于是我更改了的配置改為再次結(jié)果能達(dá)到左右差不多翻倍了結(jié)論性能問題并不那么容易解決需要耐心的排查原因 一直知道nginx本身能進(jìn)行負(fù)載均衡，但沒有測(cè)試過,今天實(shí)驗(yàn)了下,以下是筆記記錄 showImg(https://segmentfault.com/img/rem...

    xioqua 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<