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

3ewsd

　　博文缘由：
　　在上一篇博文：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.iyunv.com