nginx的$request_time 比 $upstream_response_time 的时间长很多

yekeqiang

nginx的$request_time 比 $upstream_response_time 的时间长很多，目前一个就是$request_time "9.913" $upstream_response_time 0.035 。是否nginx本身处理这个请求花费了差不多9S的时间，因此想定位到底是nginx的哪一块处理的时间长。nginx-systemtap-toolkit 工具集里面哪个工具能分析出耗时长的原因？nginx是否可以打印接收请求时间.如果可以，应该怎么做？版本为0.7.8

agentzh

Hello!

2013/7/30 keqiang ye:
> nginx的$request_time 比 $upstream_response_time 的时间长很多，目前一个就是$request_time
> "9.913" $upstream_response_time 0.035
> 。是否nginx本身处理这个请求花费了差不多9S的时间，因此想定位到底是nginx的哪一块处理的时间长。

当 $request_time 远长于 $upstream_response_time 的时候，一般意味着 nginx
花费了更多时间读取请求以及输出响应，换句话说，遇到了慢速客户端（比如很差的 wifi
网络中的用户或者慢连接攻击者或者耗时的大数据上传或大数据下载）。

> nginx-systemtap-toolkit
> 工具集里面哪个工具能分析出耗时长的原因？

Nginx Systemtap Toolkit 中目前没有现成的工具分析 nginx
单纯读取请求和单纯输出响应的延时，不过这样的工具是很容易基于 systemtap 来编写的。欢迎贡献补丁 :)

Regards,
-agentzh

yekeqiang

你好！这个分析了下耗时比较多的，确实耗时长的，比普通的数据会大，但是这个优化方法，是需要让客户端去优化客服端的报文数据？或者是我们对nginx的某些参数调优来加速读取和响应？另外以前是否有测试过一个变慢的临界值报文体的。关于分析的工具我这边试着编写一个，到时欢迎指正修改。

在 2013年7月31日星期三UTC+8上午2时54分37秒，agentzh写道：

Hello!

2013/7/30 keqiang ye:
> nginx的$request_time 比 $upstream_response_time 的时间长很多，目前一个就是$request_time
> "9.913" $upstream_response_time 0.035
> 。是否nginx本身处理这个请求花费了差不多9S的时间，因此想定位到底是nginx的哪一块处理的时间长。

当 $request_time 远长于 $upstream_response_time 的时候，一般意味着 nginx
花费了更多时间读取请求以及输出响应，换句话说，遇到了慢速客户端（比如很差的 wifi
网络中的用户或者慢连接攻击者或者耗时的大数据上传或大数据下载）。

> nginx-systemtap-toolkit
> 工具集里面哪个工具能分析出耗时长的原因？

Nginx Systemtap Toolkit 中目前没有现成的工具分析 nginx
单纯读取请求和单纯输出响应的延时，不过这样的工具是很容易基于 systemtap 来编写的。欢迎贡献补丁 :)

Regards,
-agentzh

agentzh

Hello!

2013/7/30 keqiang ye:
> 你好！这个分析了下耗时比较多的，确实耗时长的，比普通的数据会大，但是这个优化方法，是需要让客户端去优化客服端的报文数据？或者是我们对nginx的某些参数调优来加速读取和响应？

当客户和你的服务器之间的网络是性能瓶颈时，你可以尽量通过数据压缩等方式减少网络传输的数据量（比如 CSS/HTML 源码最小化以及开启 gzip 压缩）。

但如果客户端蓄意慢写慢读（比如慢连接攻击者），你其实并没有太多可以做的事情 :)

当然，定量地确定延时的具体构成，并直接定位问题的具体原因，需要使用专门的工具进行直接观察和测量了。

Regards,
-agentzh