您根据什么标准调整 HA 代理配置中的超时？

Question

配置 HA 代理时，您如何决定为超时分配哪些值？我在各种博客中阅读了六个示例，每个人都使用不同的超时时间，但没有人讨论原因。

HAProxy 似乎特别担心客户端、连接和服务器，如果您完全未设置，HAPRoxy 会发出警告：

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

该文档在这方面没有帮助：它建议“略高于 3 秒的倍数”，但不是为什么您要选择 1 对 100 或 42 的倍数。

我使用的 RPM（Amazon Linux 存储库）设置了这些默认值：

timeout connect         10s
timeout client          1m
timeout server          1m

其中两个是3 秒的精确倍数，违反了我见过的唯一官方建议。

如果您没有具体的调整建议，也许一个更简单的问题是：如果超时很短或很长，我应该会出现什么问题？

Answer 1

TCP RTO（接收超时）从三秒开始。( RFC 1122 ) 如果传输的数据包在那段时间内没有返回确认，则假定它丢失并重新传输。这几乎可以肯定是作者所指的。（请注意，RTO 会通过各种算法动态调高或调低，超出了本问题的范围。）

请记住，这实际上仅适用于您的前端服务器和客户端（即 Web 用户）之间的连接。在正常情况下，HAProxy 和您的后端服务器之间的连接应该在 LAN 上，您应该使用更短的超时时间，以便故障后端更快地停止服务。

对于您的网络用户，他们中的一些人可能处于非常高延迟的连接上，例如卫星，因此可能会遇到比正常重传更高的重传。即使一切正常，使用卫星的连接上的 RTT 也可能超过 2000 毫秒。

考虑到所有这些，您通常需要非常短的超时时间timeout connect和非常长的timeout client.

对于timeout server，这取决于您的 Web 应用程序。设置超时时，请考虑所服务的 Web 应用程序的复杂性，以及在最坏的情况下处理复杂请求可能需要多长时间。如果有疑问，请提高价值。

Answer 2

前言

我已经对 HAProxy 进行了一段时间的调优，并对其进行了大量的性能测试。从 100 个 HTTP 请求/秒到 50 000 个 HTTP 请求/秒。

第一个建议是启用 HAProxy 上的统计页面。你需要监控，也不例外。如果您打算超过 10,000 个请求/秒，您还需要微调。

超时是一个令人困惑的野兽，因为它们有很大范围的可能值，其中大多数没有可观察到的差异。我还没有看到因为数字低 5% 或高 5% 而失败。10000 与 11000 毫秒，谁在乎？可能不是你的系统。

配置

我不能凭良心给出几个数字作为“每个人有史以来最好的暂停时间”。

我可以说的是最激进的超时对于 HTTP(S) 负载平衡来说总是可以接受的。如果您遇到低于这些的情况，是时候重新配置您的负载均衡器了。

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

超时客户端：

当客户端需要确认或发送数据时，不活动超时适用。在 HTTP 模式下，这个超时在第一阶段特别重要，当客户端发送请求时，以及在读取服务器发送的数据时的响应期间。

Read：这是从客户端接收 HTTP 请求标头的最长时间。

3G/4G/56k/卫星有时会很慢。尽管如此，他们应该能够在几秒钟内发送 HTTP 标头，而不是 30 秒。

如果有人连接太差，请求一个页面需要 30 多秒（然后请求 10 个嵌入图像/CSS/JS 需要 10*30 多秒），我相信拒绝他是可以接受的。

超时服务器：

当服务器需要确认或发送数据时，不活动超时适用。在 HTTP 模式下，在服务器响应的第一阶段考虑这个超时特别重要，当它必须发送标头时，因为它直接代表服务器对请求的处理时间。要找出在那里放置什么值，通常最好从被认为是不可接受的响应时间开始，然后检查日志以观察响应时间分布，并相应地调整值。

Read：这是从服务器接收 HTTP 响应头的最长时间（在它收到完整的客户端请求之后）。基本上，这是从您的服务器开始发送响应之前的处理时间。

如果你的服务器太慢以至于需要 30 多秒才能开始给出答案，那么我相信认为它已经死了是可以接受的。

特殊情况：一些处理非常繁重的 RARE 服务可能需要整整一分钟或更长时间才能给出答案。对于此特定用途，此超时可能需要增加很多。（注意：这很可能是设计不当、使用异步样式通信或根本不使用 HTTP 的情况。）

超时连接：

设置等待连接尝试成功的最长时间。

读取：服务器必须接受 TCP 连接的最长时间。

服务器与 HAProxy 在同一个 LAN 中，所以它应该很快。至少给它 5 秒，因为这是发生任何意外情况时可能需要多长时间（丢失的 TCP 数据包要重新传输，服务器分叉新进程以接受新请求，流量激增）。

特殊情况：当服务器位于不同的 LAN 中或通过不可靠的链接时。这个超时可能需要增加很多。（注意：这很可能是架构不良的情况。）

超时检查：

设置额外的检查超时，但必须在已经建立连接之后。

设置额外的检查超时，但只有在连接已经建立之后，haproxy 使用 min("timeout connect", "inter") 作为检查的连接超时，并使用 "timeout check" 作为额外的读取超时。使用“min”是为了让运行时间很长的“超时连接”的人（例如，由于队列或tarpit而需要它的人）不会减慢他们的检查速度。（另请注意，没有正当理由有这么长的连接超时，因为“超时队列”和“超时缓送”总是可以用来避免这种情况）。

阅读：执行健康检查时，服务器必须timeout connect接受连接然后timeout check给出响应。

所有服务器都必须配置 HTTP(S) 健康检查。这是负载均衡器知道服务器是否可用的唯一方法。健康检查是一个简单的/isalive页面，总是回答OK。

将此超时设置为至少 5 秒，因为这是发生任何意外情况时可能需要多长时间（丢失的 TCP 数据包重新传输，服务器分叉新进程以接受新请求，流量激增）。

战争故事：很多人错误地认为服务器总是可以在 3 毫秒内回答这个简单的页面。他们设置了积极的超时（< 2000 毫秒）和积极的故障转移（2 次失败的检查 = 服务器死机）。我已经看到整个网站因此而瘫痪。通常情况下，流量会出现轻微的峰值，后端服务器变慢，健康检查被延迟……直到突然它们一起超时，HAProxy 认为所有服务器都立即死了，整个站点都崩溃了。