nginx之日志

 

1)耗时问题定位

这几天在优化服务器的响应时间,在根据 nginx 的 accesslog 中 requesttimerequesttime进行程序优化时,发现有个接口,直接返回数据,平均的request_time 也比较大。原来 requesttimerequesttime包含了用户数据接收时间,而真正程序的响应时间应该用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 

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"';

 

posted @ 2021-09-29 16:16  X-Wolf  阅读(216)  评论(0编辑  收藏  举报