環境：
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對靜態文件的處理還是相當的強的。