尝试做标题中所说的：保持高负载下的现有会话，并为新到访客提供503消息。
问题：它工作，但会议不会持续约90秒。
目前的结果让我想知道是否有超时设置我错过了。
我试图让haproxy：
通过这种方式，处于填写多步骤forms的访问者不会因为503错误而感到惊讶，并且新的访问者可以被告知“请稍后再来，因为我们现在真的很忙”。
设置如下：
{visitors} ↓ [haproxy] ↓ [rails app on unicorn served by nginx] (right now just one backend: 'backend-001') 为了达到上述目的，我使用下面的configuration。
这是一个非常低的限制（前端10个连接（fe_conn gt 10）），以便于testing。
为了使服务器承受一些负载，我使用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连接'）
不幸的是，您似乎完全混淆了与应用程序级会话的联系。 访问该网站的用户可能有一个cookie，这使得您认为他拥有连接，而事实并非如此。 他可能会根据需要打开多个连接来获取对象并导航页面。
您正在观察的90秒是浏览器的闲置连接超时。
有可能实现你想要的，但是比这更复杂一点，因为你还必须考虑请求中存在的持久性cookie来确定访问者是否是新的访问者。
另外一般情况下，依靠平均每个服务器的连接数量比在前端连接数量上更高效。 原因是当一台服务器死了，你需要重新调整这个数字。 最有效的方法是设置一个服务器的maxconn值来启用排队，并使用avg_queue，以使限制适用于服务器上排队请求的平均数量。 这使您可以正确处理已知的访问者，同时轻轻地将新用户移动到另一个后端，因为现有访问者负载增加。