zoukankan      html  css  js  c++  java
  • 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 

  • 相关阅读:
    dir for RequestHandler and request
    python globals和locals
    Spring AOP(通知、连接点、切点、切面)
    Elasticsearch和Head插件安装(转)
    服务发现
    全面的软件测试( 转)
    软件开发项目人员配置
    阿里云oss缩略图如何产生读取 超简单 不看后悔(转)
    Elasticsearch模糊查询
    小米Pro 安装苹果系统
  • 原文地址:https://www.cnblogs.com/liang1101/p/10395484.html
Copyright © 2011-2022 走看看