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用户请求] 的时间
问题分析
出现问题原因汇总:
- 用户端网络状况较差
- 传递数据本身较大
- 当使用 POST 方式传参时 Nginx 会先把 request body 缓存起来
这些耗时都会累积到 [1用户请求] 头上去
这样就解释了为什么 request_time 有可能会比 upstream_response_time 要大
因为用户端的状况通常千差万别 无法控制,所以并不应该被纳入到测试和调优的范畴里面
更值得关注的应该是 upstream_response_time,所以在实际工作中 如果想要关心哪些请求比较慢的话,记得要在配置文件的 log_format 中加入 $upstream_response_time
最新文章
- Java多线程之this与Thread.currentThread()的区别——java多线程编程核心技术
- 13、java中的多态
- 最小生成树算法——Kruskal算法
- tar 打包文件 除某个文件夹
- [GraphQL] Create a GraphQL Schema
- .net开发,html ajax开发架构之我见 bs ajax最简化法 Knock out Request,totally oo
- POJ 1142 Smith Numbers(史密斯数)
- LiteHttp:一款‘智能’的HTTP框架类库
- ios学习笔记block回调的应用(一个简单的例子)
- vs2013编译boost库
- C++#define的用法(含特殊)
- linux路由表配置
- 浅谈初次搭建nginx+php+mysql遇到的问题
- mysql事务介绍
- 【ASP.NET Core】依赖注入高级玩法——如何注入多个服务实现类
- 【10】Cookie和Session
- DDD - 概述 - (一)
- SpringBoot2.0之四 简单整合MyBatis
- MySQL 误删数据、误更新数据(update,delete忘加where条件)
- 给树莓派安装看门狗的两种方法,二代B