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

你可能感兴趣的:(haproxy)