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