haproxy测试

环境：

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