Performance Haproxy 1.5性能问题

我需要提高haproxy 1.5在Ubuntu 14.04实例中作为负载平衡器运行的性能。我在许多网站上都有类似于分析的代码，客户每次查看页面都会要求我们提供2-5张不同的纸条。前几天，我们在负载平衡器上每秒收到超过1k个请求，它开始运行得非常慢。它以每秒1000次的速率达到活动会话限制2000次。在配置中，我们使用选项http keep alive 100将连接保持打开状态100毫秒，直到连接关闭。我们如何才能改进这一点？这个用例的最佳配置是什么？我可能在这里失去了很多细节，请询问他们是否有信息丢失

编辑

以下是一些细节：

我正在c3.xlarge虚拟机中运行AWS ubuntu 14.04服务器。在这里，我们使用haproxy 1.5在多个应用程序实例之间平衡web流量。（每个应用程序都有自己的haproxy，可以在自己的应用程序实例之间实现负载平衡-每个核心部署一个）。 服务器只安装了haproxy，没有安装其他软件

根据haproxy统计页面，瓶颈是前端负载均衡器，因为当时它的会话速率为258，当前会话为2000（最大值为2000），所有应用程序的会话速率为96，当前会话为0/1。我会发布图片，但因为我的声誉，我不能这样做

这是当时的配置：

global
        maxconn 18000
        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/
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

defaults
        mode    http
        retries 2
        option  redispatch
        timeout connect 5s
        timeout client  15s
        timeout server  15s
        timeout http-keep-alive 1

frontend public
        log 127.0.0.1   local0  notice
        option dontlognull
        option httplog
        bind *:80
        bind *:443 ssl crt /etc/ssl/private/server.pem
        default_backend rely_apps
frontend private
        bind 127.0.0.1:80
        stats enable
        stats auth  xxx:xxx
        stats admin if LOCALHOST
        stats uri /haproxy?stats
        stats show-legends
        stats realm Haproxy\ Statistics

backend rely_apps
        option forwardfor
        balance roundrobin
        option  httpchk
        server  app1    10.0.0.1:80 check
        server  app2    10.0.0.2:80 check
        server  app3    10.0.0.3:80 check

连接非常高，似乎正在关闭它们（或以非常低的速率关闭）。 CPU和内存使用率非常低

现在，我们将该配置更改为以下配置，它可以正常工作：

global
        maxconn 64000
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        tune.bufsize    16384
        tune.maxrewrite 1024
        nbproc  4

        # 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/
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

defaults
        mode    http
        retries 2
        option  redispatch
        option forceclose
        option http-pretend-keepalive
        timeout connect 5s
        timeout client  15s
        timeout server  15s
        timeout http-keep-alive 1s

frontend public
        log 127.0.0.1   local0  notice
        option dontlognull
        option httplog
        maxconn 18000
        bind *:80
        bind *:443 ssl crt /etc/ssl/private/server.pem
        default_backend rely_apps
#frontend private
#       bind 127.0.0.1:80
        stats enable
        stats auth  xxx:xxx
        stats admin if LOCALHOST
        stats uri /haproxy?stats
        stats show-legends
        stats realm Haproxy\ Statistics

backend rely_apps
        option forwardfor
        balance leastconn
        option  httpchk
        server  app1    10.0.0.1:80 check maxconn 100
        server  app2    10.0.0.2:80 check maxconn 100
        server  app3    10.0.0.3:80 check maxconn 100

但是，所有连接在返回时都被关闭（我们的会话和请求速率相同）。 这也不好，因为我们必须为每个客户端请求打开一个新连接（每个客户端有3/4个请求）。 我们如何在不达到最大连接限制的情况下实现良好的保持活动（我认为100毫秒可以工作）

---

谢谢。

你的电话号码很低

请提供有关您的体系结构、服务器类型、运行在其上的第三方软件（如iptables）的更多详细信息，并分享您的配置

巴蒂斯特