尝试做标题中所说的:保持高负载下的现有会话,并为新到访客提供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,以使限制适用于服务器上排队请求的平均数量。 这使您可以正确处理已知的访问者,同时轻轻地将新用户移动到另一个后端,因为现有访问者负载增加。