nginx 耗時緣由定位總結

　　這幾天在優化服務器的響應時間，在根據 nginx 的 accesslog 中 $request_time 進行程序優化時，發現有個接口，直接返回數據，平均的 $request_time 也比較大。原來 $request_time 包含了用戶數據接收時間，而真正程序的響應時間應該用 $upstream_response_time。

下面分別介紹一下這兩個時間的差異：

1. request_time

　　指的就是從接受用戶請求的第一個字節到發送完響應數據的時間，即包括接收請求數據時間、程序響應時間、輸出響應數據時間。

2. upstream_response_time

　　是指從 nginx 向後端（php-cgi)創建鏈接開始到接受完數據而後關閉鏈接爲止的時間。

若是把整個過程補充起來的話 應該是：
　　［1用戶請求］［2創建 Nginx 鏈接］［3發送響應］［4接收響應］［5關閉  Nginx 鏈接］

upstream_response_time

　　那麼 upstream_response_time 就是： 2+3+4+5 
　　可是，通常這裏面能夠認爲 ［5關閉 Nginx 鏈接］ 的耗時接近 0
　　因此 upstream_response_time 實際上就是： 2+3+4 

request_time

　　request_time 是：1+2+3+4
　　兩者之間相差的就是 ［1用戶請求］ 的時間

問題分析

出現問題緣由彙總：

1. 用戶端網絡情況較差
2. 傳遞數據自己較大
3. 當使用 POST 方式傳參時 Nginx 會先把 request body 緩存起來

　　這些耗時都會累積到 ［1用戶請求］ 頭上去
　　這樣就解釋了爲何 request_time 有可能會比 upstream_response_time 要大

　　由於用戶端的情況一般千差萬別 沒法控制，因此並不該該被歸入到測試和調優的範疇裏面
　　更值得關注的應該是 upstream_response_time，因此在實際工做中 若是想要關心哪些請求比較慢的話，記得要在配置文件的 log_format 中加入 $upstream_response_time