nginx access层使用zlib解压post data和直接使用PHP gzdecode解压对比疑问

xieyuminpp

一开始使用PHP gzdecode来解压POST数据，后来发现这样做会带来高CPU负载问题。首先直接跑脚本运行，验证了在sys时间上luajit+zlib比php gzdecode要少的多。基于这一点准备使用openresty/nginx + zlib组合试试看。但是测试结果却出乎意料，nginx+zlib在access层直接解压POST数据的方式，比直接用PHP gzdecode 要慢，执行时间和系统时间都高于后者。

所有请求通过php curl模拟，post请求

测试工具 time 指令和 xhprof

access_by_lua '

local encoding = ngx.req.get_headers()["X-Body-Comprocess"]

if encoding == "gzip" then

local zlib = require "zlib"

-- post参数在接收前首先要执行这个

ngx.req.read_body()

local body = ngx.req.get_body_data()

if body then

local ix = zlib.inflate()

local inflated_str = ix(body)

ngx.req.set_body_data(inflated_str)

end

测试结果：

1. 单进程，1000次请求，php+gzdecode,

2. 单进程，1000次请求，openresty/nginx+zlib

多进程测试，100个进程，每个进程进行各自进行100次请求，每个进程的结果都上图有点麻烦，这里只给出总的时间结果。

3. 100个进程，各100次请求，php+gzdecode

4. 100个进程，各1000次请求，nginx+zlib

刚入openresty/nginx，诸位大大帮忙看看整个测试流程是哪里出了问题? 是测试的方法不对，还是应用场景的问题？

agentzh

Hello!

2015-12-31 2:42 GMT-08:00 Yumin Xie:
>
> 一开始使用PHP gzdecode来解压POST数据，后来发现这样做会带来高CPU负载问题。首先直接跑脚本运行，验证了在sys时间上luajit+zlib比php gzdecode要少的多。基于这一点准备使用openresty/nginx + zlib组合试试看。但是测试结果却出乎意料，nginx+zlib在access层直接解压POST数据的方式，比直接用PHP gzdecode 要慢，执行时间和系统时间都高于后者。
>
> 所有请求通过php curl模拟，post请求
>
> 测试工具 time 指令 和 xhprof

几点建议：

1. 使用 on-CPU 火焰图工具比较此二种服务器，php 和 nginx：

https://openresty.org/#Community

是的，C-land 火焰图工具可以作用于任意进程，不一定是 nginx.

2. 使用非 PHP 的压测工具，比如 ab 和 weighttp.

xhprof 貌似是 PHP 的分析工具，当你用它来分析 nginx 的时候，你是分析的客户端的 CPU
使用等等？这很奇怪，因为你真正感兴趣的应该是服务器端的性能。

Regards,
-agentzh

xieyuminpp

其实两个测试环境都是 nginx + php

最开始的想法，要模拟整个请求过程--从客户端到服务器再返回给客户端。这整个过程中，只有一个变量不一样，那就是解压发生的阶段--一个在nginx就解压了，一个在服务端php脚本解压。所以直接用的xhprof来检测客户端php脚本。因为客户端的请求脚本是一样的，那么如果有差距也应该是服务器层的差距。

现在想来，逻辑上还是有问题。我的确只是检测了客户端的php脚本，服务器具体什么情况我其实不知道。整个过程只是看起来只有一个变量不一样而已。

一直有感觉自己的测试方式不对，但是卡壳了好久没想明白是哪里的问题。真是一语点醒，多谢春哥。我这就换个方式测试看看。

在 2016年1月1日星期五 UTC+8上午12:31:45，agentzh写道：

Hello!

2015-12-31 2:42 GMT-08:00 Yumin Xie:
>
> 一开始使用PHP gzdecode来解压POST数据，后来发现这样做会带来高CPU负载问题。首先直接跑脚本运行，验证了在sys时间上luajit+zlib比php gzdecode要少的多。基于这一点准备使用openresty/nginx + zlib组合试试看。但是测试结果却出乎意料，nginx+zlib在access层直接解压POST数据的方式，比直接用PHP gzdecode 要慢，执行时间和系统时间都高于后者。
>
> 所有请求通过php curl模拟，post请求
>
> 测试工具 time 指令和 xhprof

几点建议：

1. 使用 on-CPU 火焰图工具比较此二种服务器，php 和 nginx：

https://openresty.org/#Community

是的，C-land 火焰图工具可以作用于任意进程，不一定是 nginx.

2. 使用非 PHP 的压测工具，比如 ab 和 weighttp.

xhprof 貌似是 PHP 的分析工具，当你用它来分析 nginx 的时候，你是分析的客户端的 CPU
使用等等？这很奇怪，因为你真正感兴趣的应该是服务器端的性能。

Regards,
-agentzh

agentzh

Hello!

2016-01-01 23:37 GMT-08:00 Yumin Xie:
> 其实两个测试环境都是 nginx + php
>
> 最开始的想法，要模拟整个请求过程--从客户端到服务器再返回给客户端。这整个过程中，只有一个变量不一样，那就是解压发生的阶段--一个在nginx就解压了，一个在服务端php脚本解压。所以直接用的xhprof来检测客户端php脚本。因为客户端的请求脚本是一样的，那么如果有差距也应该是服务器层的差距。
>

我有一种理论，即你两个服务器端实际使用的压缩级别（compression level）不一样，而 nginx
使用的压缩比率更高，所以解压也需要客户端花费更多的 CPU 时间。

Regards,
-agentzh

xieyuminpp

抱歉，隔了好几天才回。接近年关，零碎时间变得更少了。花了好些天，才学习上这些新的工具。

一开始是macosx系统，没办法直接使用systemtap。所以，搞了个虚拟机centos 7 , 内核版本：3.10.0-327.3.1.el7.x86_64 。花了点时间重新搭建了环境。

为了观测nginx进程，采用了 https://github.com/openresty/nginx-systemtap-toolkit#sample-bt 这个脚本。

./sample-bt -p 27414 -t 5 -u -k > gzdecode.bt

...blablabla...

WARNING: too many pending (warning) messages

WARNING: Time's up. Quitting now...(it may take a while)

ERROR: Skipped too many probes, check MAXSKIPPED or try again with stap -t for more details.

在监控追踪的同时，我会去请求服务器端的解压脚本（http_load 以及循环curl post两种都尝试了）

这里有一个问题，那就是sample.bt 会卡在最后一步很久，然后失败。在多次的实验中，只有一次成功输出可用的追踪数据，生成flame图。

同理还测试过：sample-bt-off-cpu、sample-bt-vfs 都是最后一步卡好久，然后失败。

春哥，这个脚本工具在使用过程中有没有什么需要注意的地方？是否符合我当前的使用需求？

在 2016年1月3日星期日 UTC+8上午1:32:30，agentzh写道：

Hello!

2016-01-01 23:37 GMT-08:00 Yumin Xie:
> 其实两个测试环境都是 nginx + php
>
> 最开始的想法，要模拟整个请求过程--从客户端到服务器再返回给客户端。这整个过程中，只有一个变量不一样，那就是解压发生的阶段--一个在nginx就解压了，一个在服务端php脚本解压。所以直接用的xhprof来检测客户端php脚本。因为客户端的请求脚本是一样的，那么如果有差距也应该是服务器层的差距。
>

我有一种理论，即你两个服务器端实际使用的压缩级别（compression level）不一样，而 nginx
使用的压缩比率更高，所以解压也需要客户端花费更多的 CPU 时间。

Regards,
-agentzh

xieyuminpp

多次测试后，发现问题出现在了 -u 参数上，也就是追踪user space的时候，会出现卡死的问题。kernel space 的话，脚本运行起来没有任何问题。

在 2016年1月7日星期四 UTC+8下午3:26:02，Yumin Xie写道：

抱歉，隔了好几天才回。接近年关，零碎时间变得更少了。花了好些天，才学习上这些新的工具。

一开始是macosx系统，没办法直接使用systemtap。所以，搞了个虚拟机centos 7 , 内核版本：3.10.0-327.3.1.el7.x86_64 。花了点时间重新搭建了环境。

为了观测nginx进程，采用了 https://github.com/openresty/nginx-systemtap-toolkit#sample-bt 这个脚本。

./sample-bt -p 27414 -t 5 -u -k > gzdecode.bt

...blablabla...
WARNING: too many pending (warning) messages
WARNING: Time's up. Quitting now...(it may take a while)
ERROR: Skipped too many probes, check MAXSKIPPED or try again with stap -t for more details.

在监控追踪的同时，我会去请求服务器端的解压脚本（http_load 以及循环curl post两种都尝试了）

这里有一个问题，那就是sample.bt 会卡在最后一步很久，然后失败。在多次的实验中，只有一次成功输出可用的追踪数据，生成flame图。

同理还测试过：sample-bt-off-cpu、sample-bt-vfs 都是最后一步卡好久，然后失败。

春哥，这个脚本工具在使用过程中有没有什么需要注意的地方？是否符合我当前的使用需求？
在 2016年1月3日星期日 UTC+8上午1:32:30，agentzh写道：
Hello!

2016-01-01 23:37 GMT-08:00 Yumin Xie:
> 其实两个测试环境都是 nginx + php
>
> 最开始的想法，要模拟整个请求过程--从客户端到服务器再返回给客户端。这整个过程中，只有一个变量不一样，那就是解压发生的阶段--一个在nginx就解压了，一个在服务端php脚本解压。所以直接用的xhprof来检测客户端php脚本。因为客户端的请求脚本是一样的，那么如果有差距也应该是服务器层的差距。
>

我有一种理论，即你两个服务器端实际使用的压缩级别（compression level）不一样，而 nginx
使用的压缩比率更高，所以解压也需要客户端花费更多的 CPU 时间。

Regards,
-agentzh