這幾天在優化服務器的響應時間，在根據 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用戶請求］ 的時間
問題分析
出現問題原因匯總：
- 用戶端網絡狀況較差
- 傳遞數據本身較大
- 當使用 POST 方式傳參時 Nginx 會先把 request body 緩存起來
這些耗時都會累積到 ［1用戶請求］ 頭上去
這樣就解釋了為什么 request_time 有可能會比 upstream_response_time 要大
因為用戶端的狀況通常千差萬別 無法控制，所以並不應該被納入到測試和調優的范疇里面
更值得關注的應該是 upstream_response_time，所以在實際工作中 如果想要關心哪些請求比較慢的話，記得要在配置文件的 log_format 中加入 $upstream_response_time