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