在configuration高可用性代理时，您如何决定分配给超时的值？ 我已经在不同的博客上读了六十个样本，每个人都使用不同的超时时间，没有人讨论为什么。
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秒的倍数”，但不是为什么你会select1比100或42的倍数。
我使用的RPM（Amazon Linux存储库）设置了这些默认设置：
timeout connect 10s timeout client 1m timeout server 1m
其中两个是3秒的精确倍数，违反了我见过的唯一官方build议。
如果您没有具体的调整build议，也许更容易的问题是：我真的应该预料什么时候会出现短暂的或真正的超时？
TCP RTO（接收超时）从三秒钟开始。 （ RFC 1122 ）如果一个传输的数据包在那个时候还没有得到确认，那么它就被认为是丢失并重新传输的。 这几乎可以肯定作者所指的是什么。 （请注意，RTO可以通过各种algorithm进行dynamic调整，超出了这个问题的范围。）
请记住，这只适用于您的前端服务器和客户端（即Web用户）之间的连接。 在正常情况下，HAProxy和后端服务器之间的连接应该在局域网上，并且应该使用更短的超时时间，以便故障后端尽早停止服务。
至于您的networking用户，他们中的一些可能处于非常高的延迟连接（例如卫星），并且可能由于此而经历高于正常的重传。 即使一切正常，卫星正在使用的连接上的RTT可能会超过2000毫秒。
考虑到这一切，您通常会希望timeout connect超时timeout connect非常短， timeout client的timeout client非常长。
对于timeout server ，这取决于您的Web应用程序。 设置超时时，请考虑所提供的Web应用程序的复杂程度，以及在最糟糕的情况下处理复杂请求需要多长时间。 如果有疑问，请提高价值。
我一直在调整HAProxy一段时间，并做了大量的性能testing。 从100个HTTP请求/秒到50 000个HTTP请求/秒。
第一个build议是启用HAProxy的统计页面 。 你需要监控，也不例外。 如果您打算超过10000个请求/秒，您还需要进行微调。
超时是一个令人困惑的野兽，因为它们有很大的可能值，其中大部分没有明显的差异。 我还没有看到什么失败，因为数字低5％或5％。 10000 vs 11000毫秒，谁在乎？ 可能不是你的系统。
我不能良心地给出几个数字作为“每个人的最佳超时”。
我可以告诉的是，对于HTTP（S）负载平衡来说，最主动的超时时间总是可以接受的。 如果遇到这种情况，则应该重新configuration负载均衡器。
timeout connect 5000 timeout check 5000 timeout client 30000 timeout server 30000
不活动超时适用于客户端需要确认或发送数据时。 在HTTP模式下，在第一阶段，客户端发送请求时以及在读取由服务器发送的数据的响应期间，这个超时特别重要。
阅读 ：这是从客户端接收HTTP请求标头的最长时间。
3G / 4G / 56k /卫星有时可能会变慢。 不过，他们应该能够在几秒钟内发送HTTP头，而不是30。
如果某个人的连接非常糟糕，需要一个页面超过30秒（然后超过10 * 30s请求10个embedded的图像/ CSS / JS），我相信拒绝他是可以接受的。
当服务器预期确认或发送数据时，不活动超时应用。 在HTTP模式下，在服务器响应的第一阶段，必须发送标题时，这个超时是特别重要的，因为它直接代表了服务器对请求的处理时间。 为了找出在这里放置什么样的价值，开始时应该考虑不可接受的响应时间，然后检查日志以观察响应时间分布，并相应地调整值。
阅读 ：这是从服务器接收HTTP响应头的最大时间（在收到完整的客户端请求之后）。 基本上，这是从服务器开始发送响应之前的处理时间。
如果你的服务器太慢了，需要30多秒才能开始给出答案，那么我相信认为它是死的是可以接受的。
特殊情况 ：一些处理非常繁重的RARE服务可能需要一整分钟或更长时间来给出答案。 这个超时可能需要增加很多这个具体的用法。 （注意：这可能是一个糟糕的devise，使用asynchronous风格的通信或根本不使用HTTP）。
设置等待到服务器的连接尝试成功的最长时间。
阅读 ：服务器必须接受TCP连接的最长时间。
服务器与HAProxy在同一个局域网中，所以它应该很快。 至less给5秒钟，因为当发生任何意外事件（丢失的TCP数据包重新传输，服务器分叉新的请求，stream量高峰）时，可能需要多长时间。
特殊情况 ：当服务器位于不同的局域网或不可靠的链路上时。 这个超时可能需要增加很多。 （注：这可能是一个糟糕的架构的情况。）
设置额外的检查超时，但只有在连接已经build立之后。
设置额外的检查超时，但只有在已经build立连接后，如果设置，haproxy使用min（“timeout connect”，“inter”）作为连接超时进行检查和“超时检查”作为附加读取超时。 使用“min”是为了使运行时间很长的“超时连接”的人（例如，由于队列或者tarpit而需要这些的人）不会减慢他们的检查。 （请注意，没有合理的理由可能导致连接超时，因为总是可以使用“timeout queue”和“timeout tarpit”来避免）。
阅读 ：执行健康检查时，服务器有timeout connect接受连接，然后timeout check给出响应。
所有服务器都必须configurationHTTP（S）运行状况检查。 这是负载均衡器知道服务器是否可用的唯一方法。 健康检查是一个简单/isalive页面，总是回答OK 。
给这个超时至less5秒，因为当发生任何意外事件（丢失的TCP数据包重新传输，服务器分叉新的请求，stream量高峰）时，可能需要多长时间。
战争的故事 ：很多人错误地认为，服务器总是可以在3毫秒内回答这个简单的页面。 他们设置积极的超时（<2000毫秒）与积极的故障转移（2失败检查=服务器死亡）。 我看到整个网站都因此而下滑。 通常情况下，stream量会有轻微的上升，后端服务器变慢，健康检查被延迟……直到突然间，他们都一起超时，HAProxy认为所有的服务器立即死亡，整个网站停止。