haproxy测试

sqtsqt

　　环境：
　　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对静态文件的处理还是相当的强的。