我目前有一个运行在PHP-FPM和APC的Nginx平台上的站点。 我一直在尝试的testingperformance非常好。
我现在想添加故障转移function，不能负担硬件负载均衡器，所以看着使用HAProxy。
这更多的是一个理论问题，但是两个Nginx服务器将能够提供比HAProxy更多的页面，并且意味着HAProxy将成为潜在的瓶颈。
开箱即用的haproxy使用双向路由，如果您的堆栈中有这个路由，它所传递的任何请求的响应都会通过它返回。 有一种方法（我从来没有尝试过，所以不能提供任何洞察力），使其透明，其中原来的IP被传递在它转发的请求。 但是这涉及重新编译内核，可能不是你想要closures的路线。 如果你想探索，谷歌“tproxy”。
我使用haproxy来平衡nginx-squid-haproxy-zope_clients堆栈中的Plone客户后端，并没有经历任何归因于haproxy的瓶颈。 就像vesterday所说，haproxy只是使用内存规则集来路由stream量。 如果你的服务器有足够的资源，而且你没有陷入交换，那么haproxy将成为你最担心的问题，即使如此，我还是会首先考虑其他的问题。
HAProxy不太可能成为你的瓶颈，因为它只是路由连接，并不能完成Web服务器通常要做的所有事情。
但是，您可能希望确保单独的HAProxy实例不能成为单点故障。
HAProxy将是你最担心的问题 – 它只是路由请求。 虽然有些时候你会看到错误信息，仔细检查后发现问题通常来自后端服务器（容量问题，可用性，应用程序错误等）。
根据我的经验，我有一个HAProxy的故障转移设置和5年（和计数），它没有被使用！ 有趣的是，如果你像我这样的偏执狂，你可以在所有图层上设置故障转移。 （我使用keepalived 。）