haproxy 优化参数解释
option http-server-close
假设你有一台HAProxy前端与十个不同的后端通信，且这十个后端不支持HTTP keep-alive。这个设置让HAProxy在客户端和前端之间保持一个持久的连接，并在所有后端服务器之间轮询HTTP请求。当然，要发挥这个设置的功效的话需要客户端同样启用keep-alive。
timeout client 30s
timeout server 30s
这两个设置一起用来设置 HAProxy发送请求的超时时长。实际上，HAProxy等待服务器返回信息给客户端需要多久呢？大多数应用都有某种最大延迟时间，因此你需要添加超时时长。对我们来说，API等待响应的最长时间是30秒，所以每个内部服务根据自身的服务级等级协议（SLA）都应该设置低于30秒的超时时长。注意：如果服务器缓慢地以流的方式传输一个字节，也就是每29秒传输一个字节的话，你将不能触发读超时，所以你可能需要有一个单独的线程监控这样的请求，以保证在适当的时间内完成传输。你还应当把客户端和服务端的超时时长设置为相同的值-即套接口上所期望的读超时时长。
timeout connect 3100
这是一个不同于客户端和服务端超时时长的超时时长！它是HAProxy应当用来试图连接主机所花费的时长。在RWilio以前的日子里，它设置为与服务器超时时长30秒相同的值，因此如果主机宕机的话，HAProxy将试图连接同一个主机30秒。当服务器和客户端主机位于同一个机器上或者在同一个局域网内（或者AZ主机的附近）的时候，这样的连接通常发生在毫秒级。我们允许在进一步处理默认的重传窗口时等待3秒，并且允许有小量的缓冲。
不像服务器超时时长，连接超时时长隐含着客户端的重新连接请求是安全的这层意思。
retries 2
option redispatch
当我说30秒的连接超时时长意味着HAProxy将在30秒内试图进行一次未连接上的连接的时候，我撒谎了。实践证明： 默认情况下,HAProxy将试图进行3次连接请求。因此30秒的连接超时实际上是120秒的连接超时，这违反了服务级别协议，而且意味着我们给客户兑现的是空头支票。
如果第一台主机关机了，那么通常假设HAProxy自动给第二台主机发送请求。不过这仅仅在HAProxy对这个主机进行健康检查后并标记这台主机已经关机的情况下才是这样的。如果一台主机关机了而且对它的健康检查花费了20秒，那么这时你正在对这台主机进行可能的20秒的无效请求。重新分发选项让最终的连接请求发送给另一台下游主机上，因此不同主机发送各自的请求在某种程度上保护了已经不健康的主机。
这两个设置混合在一起缩减重试次数到2，并且这也意味着在放弃这个连接并对另一台主机进行连接之前，我们试图对这台主机进行连接的最大超时时长只有8秒。
option httpchk GET /healthcheck
默认情况下，HAProxy只是对主机打开了一个TCP连接来检查这台主机是否启动。这种ping只能检测这台主机是否关机，不过不能确定它是不健康的（磁盘损坏，网络连接不正常）。httpchk选项将给位于后端的终端节点发送HTTP请求。后端可以进行自检，并回答自身是否健康。注意健康检查应当是相当保守的一种做法，而且通常还扩大了单台主机健康的范围。健康检查未通过将使HAProxy给这台主机不发送任何包，而且如果所有的主机同时都“不健康”，那么你将没有任何后端可依赖了。 我希望这篇文章对你有帮助-我已经在 这儿发布了HAProxy配置的所有更新版本。至于其他问题， 可以阅读手册，这样可以让服务器在性能、可靠性、可用性和稳定性方面得到很大的提高。希望这篇概览能够节省你的时间。
