Nginx/Tengine buffer request data所存在的性能风险

博文缘由：

在上一篇博文：TCP Delay引起的性能问题 —— tengine request no buffering性能测试回顾 中提到“当访问压力较大且post数据超过buffer大小，那么nginx/tengine将会有大量的io操作，从而存在性能风险”。所谓空口无凭，下面通过展现性能测试数据来说明该风险。

 

性能测试设计及数据展现：

为了节约篇幅，在此取较容易体现性能差异的性能场景进行分析，如果想了解其他场景性能，欢迎联系我；

性能场景：

1. 通过POST上传100K大小的文件；

2. 设置系统Sync间隔时间为1s；

3. 默认Buffer状态和no buffer 8k、64k、640k对比；

4. 并发连接数分别为30、150、300、1500；

 

部署Nginx服务器的性能：

软件情况描述：

1、Red Hat Enterprise Linux Server release 6.1 (Santiago)

2、gcc version 4.4.6 20110731 (Red Hat 4.4.6-3)

3、Linux SandyBridge 2.6.32-131.21.1.tb93_v2.el6.x86_64

硬件情况描述：

1、cpu cores       : 8

2、Genuine Intel(R) CPU  @ 2.70GHz

3、内存总数32791984kB

4、万兆网卡

 

性能测试结果分析：

分析说明：

从以下数据图表可以看出：

1. 在QPS与服务器请求平均处理时间上看，默认Buffering的场景与no buffering 8k、64k、640k的场景相差无几。

这是因为默认Buffering场景是在全部接收完Client上传数据之后再分多个大数据包往后传，网络传输率较高，瓶颈体现在io操作上；而no buffering的场景，是在从Client接收的数据达到buffer所设置的值之后就马上往后端传送，因此网络传输利用率较低，存在很多小包发送的问题，从而影响性能。

2. 从服务器性能负载的角度看，默认Buffering的场景非常消耗机器资源，Load超过2倍CPU核数，iowait百分比最高达到28%；而no buffering的场景则没有占用太多机器资源；

 

数据展现： 

图1 QPS变化曲线图

 

图2 服务器请求平均处理时间

 

图3 CPU IOWait百分比变化曲线图

 

图4 Load每分钟统计结果变化曲线

图5 网络输入数据变化曲线图

 

图6 网络输出数据变化曲线图

 

 

 转发请备注转自：100continue.iteye.com