环境：
Clients：N台linux， 使用“ab -k -c 20000...” 并发2w 请求haproxy
Haproxy Server: R610 2*8核 2.4G
Real Server： IIS6 （50字节 html静态文件）
使用一台客户端向haproxy发起20000并发请求，如下：
1. option httpclose
7000/s
2. option http-server-close
10000/s
3.keepalive
20000/s
4. nbproc=8 （前面nbproc=1）
2000/s (8个进程，平均CPU 30%)，单核心%si 达到65%，性能不升反降 。
后来想想是测试机器的网卡不行，多队列启动不来。
使用5台client 想haproxy 发起2w*5=10w 并发请求：
4000/s，session数稳定在6.5w，监控界面打开已经很困难了，请求延时很厉害了。
配置haproxy最大session数为40w，但还是无法超越65535 这个ulimit值，root账号可以没连接数限制的，应该是haproxy实现问题
7.25更新:
没有改ulimit 值默认1024，haproxy启动是会根据配置setrlimit 设置到配置到的nofile数，root运行设置是ulimit的。多谢@lj098提醒
/etc/security/limits.conf 中nofile 值最大不是65535，而完全可以更大。
还有就是这个测试中多进程效率不提速，后来才发现是测试那台机器网卡问题，中断都在一个核心，多进程时，每个进程都会accept连接，之后处理
按理如果中断均衡的话receive data 可以分散到各个核心，性能就能成倍提高了。
在新的机器上重新测试：
使用：redis-benchmark->Haproxy->redis 方式测试tcp转发，get请求
单进程：6.5w/s 100%CPU（相比twenproxy要快一些呢）
2进程： 12w/s 100%*2CPU
4进程： 15w/s 65%*4 CPU
总的来说，一定程度上使用多进程与单进程性能成比例的，因为不同连接上业务负载差不多，多进程负载还是比较均匀的。
====
整个过程IIS峰值 2w/s请求 、2w并发连接数，cpu占用8%左右，从这儿看来IIS6对静态文件的处理还是相当的强的。