☰

使用 Haproxy 在 http 模式下无法超过每秒约 11K 个请求

tag-icon • tag-icon linux load-balancing haproxy
使用 Haproxy 在 http 模式下无法超过每秒约 11K 个请求

我无法让每个 haproxy 实例每秒获得超过 11K 个请求。

我在 amazon EC2 上有两个 haproxy 实例。均在 c4.xlarge 实例下。我尝试配置 maxconn 参数、cpu 映射和 linux 限制，但没有任何效果。

我正在使用 jmeter 进行测试，如果我运行两个并行的 jmeter，配置为攻击其中一个 haproxy，我设法获得大约 22K，但如果我执行相同的配置但都只攻击 1 个 haproxy 实例，则最大吞吐量为 11K。

我的 haproxy 配置是：

global
    nbproc 4
    cpu-map 1 0
    cpu-map 2 1
    cpu-map 3 2
    cpu-map 4 3
    maxconn 150000
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    # An alternative list with additional directives can be obtained from
    #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    option      http-server-close
    retries     2
    timeout     http-request    10s
    timeout     queue           1m
    timeout     connect         5s
    timeout     client          1m
    timeout     server          1m
    timeout     http-keep-alive 20s
    timeout     check           15s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http



frontend DSP_FRONT
    bind *:80
    maxconn 300000
    default_backend DSP_BACK

backend DSP_BACK
    balance hdr(device)
    mode http
    server dsp1 172.31.3.141:80 check
    server dsp2 172.31.8.195:80 check
    server dsp3 172.31.8.186:80 check


listen stats 
    bind :9000
    mode http
    stats enable
    stats hide-version
    stats realm HAproxy-Statistics
    stats uri /haproxy_stats

后端应该非常快并且响应长度相当小（0.5-1kb）。

我也尝试突破系统限制。

fs.file-max = 10000000 
fs.nr_open = 10000000
net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216
net.ipv4.ip_local_port_range = 1000 65535

并将文件限制添加到 haproxy systemd 服务中

限制NOFILE=300000

但好像没什么变化。

我在 ubuntu 16.04 下运行 haproxy

法律：

cat /proc/[haproxyprocid]/limits 的输出

ubuntu@ip-172-31-1-115:~$ ps ax| grep ha
 1214 ?        Ss     0:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
 1217 ?        S      0:00 /usr/sbin/haproxy-master
 1218 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1219 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1220 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1221 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1393 pts/0    S+     0:00 grep --color=auto ha
ubuntu@ip-172-31-1-115:~$ cat /proc/1217/limits 
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             29852                29852                processes 
Max open files            300035               300035               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       29852                29852                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

答案1

您没有提到限制因素是什么。首先，您在共享虚拟机上运行，​​因此只有托管服务提供商知道他们是否为您提供了真正的 CPU。其次，如果您强调 SSL，则可能会最大化 CPU。11k req/s 可能或多或少与中等机器上恢复 TLS 连接的预期相匹配。在这种情况下，您会看到 haproxy 使用了 100% 的 CPU，主要是在用户空间（通常为 60% 用户/40% 系统）。如果您正在执行 11k RSA2048，那么恭喜您，因为它很大！如果您在清晰的连接上执行此操作，则它很低，但可能完全由虚拟机环境引起。如果它是在保持活动连接上，它确实太低了，甚至可能是由巨大的网络延迟引起的（在极度超额预订的虚拟机中也很常见）。

相关内容