haproxy：在高负载下保留现有会话，为新来者提供“503”服务

Question

尝试做标题中所说的：在高负载下保留现有会话，并向新到达的访问者提供 503 消息。

问题：它有效，但会话不会持续超过大约 90 秒。

目前的结果让我想知道是否有我缺少的超时设置。

目的

我试图让haproxy：

• 当前端的会话总数低于某个阈值时，将新会话的请求发送到 backend-001。
• 当前端的会话总数高于该阈值时，向新会话提供 503 错误
• 即使会话数超过阈值，也允许对现有会话的请求

这样，正在填写多步骤表单的访问者不会对 503 错误感到惊讶，并且可以告诉新访问者“请稍后再回来，因为我们现在真的很忙”。

设置

设置如下：

            {visitors}
                ? 
            [haproxy]
                ? 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

目前的方法

为了实现上述目标，我正在使用以下配置。

这个是用于测试的，有一个非常低的限制（前端10个连接（fe_conn gt 10）），使测试更容易。

为了让服务器承受一定的负载，我使用 httperf 如下：

httperf --hog --server staging.machine.tld --uri /do_some_things --wsess=500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

问题

如上所述，问题是：它几乎可以工作，但会话不会持续超过大约 90 秒。

如果您继续点击，即使有 10 个会话繁忙，您也可以保持会话。

尝试使用不同的浏览器实例在服务器上打开页面会导致 503 错误。

所以，看起来我快到了。有没有人知道是什么导致了较短的会话时间？

尤其是我如何解决它:)

（编辑：从“服务器”行中删除了“权重 1 maxconn 10”，不相关并且可能会造成混淆）（编辑第二个：将“前端的 10 个会话”更正为“前端的 10 个连接”）

Answer 1

不幸的是，您似乎完全混淆了应用程序级会话的连接。访问该网站的用户可能拥有一个 cookie，这让您认为他拥有一个连接，但事实并非如此。他可以根据需要打开任意数量的连接来获取对象和导航页面。

您观察到的 90 秒肯定是浏览器空闲连接的保持活动超时时间。

可以实现您想要的目标，但比这更复杂一些，因为您还必须考虑请求中是否存在持久性 cookie，以确定访问者是否是新访问者。

此外，一般来说，依赖每台服务器的平均连接数比依赖前端连接数更有效。原因是当一个服务器死掉时，你需要重新调整这个数字。最有效的方法是设置服务器 maxconn 值以启用排队，并使用 avg_queue 以便该限制适用于服务器上排队请求的平均数量。这使您可以正确处理已知访问者，同时在现有访问者造成负载增加时将新用户轻轻移动到另一个后端。