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