并发 TCP 连接的数量是负载均衡器的限制因素吗?

并发 TCP 连接的数量是负载均衡器的限制因素吗?

我试图了解负载平衡器上的并发 TCP 连接数是否是“正常”网站的限制因素,而不是数据吞吐量。

当我查看负载平衡器的数据表时,我找不到有关它们可以处理多少个连接的信息。这是否意味着连接数不是限制因素,还是意味着很难判断,因为除了连接数之外,其他因素更为重要?

最后,我试图弄清楚我们的负载均衡器何时会因为网站访问者过多而崩溃。这是一个虚拟负载均衡器,即 Barracuda BBF 340 Vx,配有 2 GB 内存和 2 个 CPU。

答案1

通常不会。对于大多数网站来说,http 连接的正常“无状态”行为意味着连接可能会很快被断开。例如,Apache 的默认超时时间为 15 秒,IIS 为 2 分钟(尽管可以缩短)。

更糟糕的情况是,您启用了会话亲和性,并且连接超时时间较长(15 分钟、30 分钟等或更长),并且有大量独立访问者。在这种情况下,最大连接数可能会低几个数量级。这种高连接负载的设计很少见。

答案2

设备支持的并发 TCP 连接数始终A限制因素-每个操作系统都有一个内部表来跟踪 TCP 连接的状态,并且该表的可能条目数量有限。

在典型情况下,TCP 连接数不会限制因素:该限制非常高,以至于在达到该限制之前,您会先达到环境的其他限制。例如,如果您的负载均衡器正在为您的环境处理 SSL 加密,那么在达到 TCP 连接限制之前,您可能会先达到 CPU/RAM 限制。


从供应商处获取此数字的实用性值得怀疑——供应商会撒谎。他们通常会提供理论上最佳情况下的最大数字(这在任何实际生产环境中通常都不可能实现)。
您可以从评论网站获取第三方数据,但真正了解您的环境限制的唯一方法是对你的环境进行负载测试假设你能创造足够的工作,你将要导致您的环境失败,您将能够找出原因。(然后您可以决定性能/限制是否可接受 - 如果不可接受,您可以努力改善您的环境以处理预期的负载。)

相关内容