nginx中request_time/upstream_resp
一、request_time与upstream_response_time比较
image.png
request_time
指的就是从接受用户请求的第一个字节到发送完响应数据的时间，即$request_time包括接收客户端请求数据的时间、后端程序响应的时间、发送响应数据给客户端的时间(不包含写日志的时间)。
image.png
upstream_response_time
是指从Nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间。
一般request_time比upstream_response_time大
如果用户端网络状况较差 或者传递数据本身较大
再考虑到 当使用 POST 方式传参时 Nginx 会先把 request body 缓存起来
而这些耗时都会累积到用户请求上去
这样就解释了：为什么 request_time 有可能会比 upstream_response_time 要大。
因为用户端的状况通常千差万别 无法控制 ，所以并不应该被纳入到测试和调优的范畴里面
更值得关注的应该是 upstream_response_time
所以在实际工作中 如果想要关心哪些请求比较慢的话，记得要在配置文件的 log_format 中加入 $upstream_response_time
upstream_response_time比request_time 大
upstream_response_time由clock_gettime(CLOCK_MONOTONIC_COARSE)计算，默认情况下，它可以过去4毫秒，相反，$ request_time由gettimeofday()计算。 所以最终upstream_response_time可能比response_time更大。
指导：
所以在通过nginx的access_log来分析后端程序接口响应的时候，需要在nginx的log_format中添加$upstream_response_time字段。
二、在新的Nginx版本中对整个请求各个处理阶段的耗时做了近一步的细分
$upstream_connect_time(1.9.1)：
跟后端server建立连接的时间，如果是到后端使用了加密的协议，该时间将包括握手的时间。
$upstream_header_time(1.7.10)：单位为秒。
接收后端server响应头的时间。
流程说明
如果把整个过程补充起来的话 应该是：
- 用户请求
- 建立 Nginx 连接
- 发送响应
- 接收响应
- 关闭 Nginx 连接
upstream_response_time 就是 2+3+4+5 但是 一般这里面可以认为 ［5关闭 Nginx 连接］ 的耗时接近 0，所以 upstream_response_time 实际上就是 2+3+4 。而 request_time 是 1+2+3+4。二者之间相差的就是 ［1用户请求］的时间。
示意图
img
- 程序真正的运行时间 =
$upstream_header_time - $upstream_connect_time - $request_time 中包含了数据返回时间
- $request_time 中包含了日志打印的时间
三、场景
nginx日志出现大量超时报警，这个时候发现
request_time、$upstream_response_time很大
分析：根据上面的示意图，这个时候便反映出是上游程序执行较慢、或发送数据量大，需要排查执行程序的相关慢日志。
同样是ngxin日志出现大量超时报警，这个时候发现
upstream_response_time正常
分析：$upstream_response_time正常，说明程序执行完毕且正常返回，那么这个时候需要验证是数据返回过慢还是日志打印出现了阻塞。
原因：
- 数据返回慢可以通过抓包分析，通常来说是用户网络原因引起的；
- 日志打印出现阻塞，可能是机器io出现了问题，这个一般很容易发现；
- 还有可能是nginx配置了相关参数，导致了延迟关闭，这里只要根据问题现象一步一步排查即可。
- 也可能返回给客户端是https，大数据加解密耗时
解决方法：
- 把你的服务器放在high-speed network高性能网络上，让client能够快速访问
- 使用缓存CND、Nginx缓存
- 或者将你的服务器靠近用户，多IDC进行对不同区域用户服务。如：中国IDC、韩国IDC
- 去掉一些低效率算法，参考： Nagle's algorithm
- 调整服务器的TCP堆栈（参考 这篇文章）. 然而调整TCP堆栈不会有多大作用，因为内核默认配置已经做了优化调整了。
$upstream_connect_time很大
可能是网络通信出现了问题；
$upstream_header_time很小，但是$upstream_response_time很大
可能是数据回写nginx出现了问题。
文章整理自：
https://blog.csdn.net/zzhongcy/article/details/105819628
https://www.cnblogs.com/dongruiha/p/7007801.html
