配置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秒的精确倍数，这违反了我所见的唯一官方建议。

如果您没有具体的调优建议，则可能更简单的问题是：如果超时时间太短或太长，我应该怎么办？

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

请记住，这实际上仅适用于前端服务器和客户端（即Web用户）之间的连接。在正常情况下，HAProxy与后端服务器之间的连接应位于LAN上，并且应使用更短的超时时间，以便有故障的后端能尽快退出服务。

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

考虑到所有这些因素，您通常会希望超时时间很短，timeout connect而超时时间却很长timeout client。

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

前言

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

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

超时是一个令人困惑的野兽，因为它们具有很大的可能值范围，其中大多数没有明显的区别。我还没有看到由于数字低5％或高5％而失败的情况。10000 vs 11000毫秒，谁在乎？可能不是您的系统。

组态

我不能凭良心给出几个数字，作为“有史以来最适合每个人的超时时间”。

我可以说的是，MOST积极的超时对于HTTP（S）负载平衡总是可以接受的。如果您遇到的负载不足，则该重新配置负载均衡器了。

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

超时客户端：

不活动超时适用于预期客户端确认或发送数据的情况。在HTTP模式下，在第一阶段，客户端发送请求时以及在读取服务器发送的数据的响应期间，必须考虑此超时。

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

3G / 4G / 56k /卫星有时会变慢。不过，他们应该能够在几秒钟内（而不是30秒）发送HTTP标头。

如果某人的连接质量很差，要求一个页面需要30秒以上的时间（然后请求10张嵌入式图像/ CSS / JS的时间超过10 * 30s），我认为可以拒绝他。

超时服务器：

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

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

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

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

超时连接：

设置等待连接服务器成功的最长时间。

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

服务器与HAProxy处于同一LAN中，因此应该很快。给它至少5秒钟的时间，因为这是发生任何意外事件（丢失的TCP数据包重新传输，服务器分叉一个新进程来接收新请求，流量激增）所花费的时间。

特殊情况：服务器位于其他LAN或不可靠的链接上时。此超时可能需要增加很多。（注意：这很可能是架构不良的情况。）

超时检查：

设置其他检查超时，但仅在建立连接之后。

设置其他检查超时，但仅在已经建立连接之后。如果设置，则haproxy将min（“ timeout connect”，“ inter”）用作检查的连接超时，并将“ timeout check”用作其他读取超时。使用“ min”是为了使运行“超时连接”时间很长的人员（例如，由于队列或tarpit而需要连接的人员）不会减慢检查速度。（也请注意，没有足够的理由使连接超时如此之长，因为始终可以使用“超时队列”和“超时tarpit”来避免这种情况）。

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

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

给此超时至少5秒钟，因为这是发生任何意外事件（丢失的TCP数据包重新传输，服务器分叉一个新进程以接收新请求，流量激增）所花费的时间。

战争故事：许多人错误地认为服务器总是可以在3毫秒内回答这个简单的页面。他们通过主动故障转移（两次失败的检查=服务器死机）设置了主动超时（<2000ms）。因此，我看到整个网站都关闭了。通常情况下，流量会略有增加，后端服务器会变慢，运行状况检查会延迟……直到突然它们全部超时，HAProxy认为所有服务器会立即死亡，整个站点都将关闭。