为什么mod_proxy_协议或ELB会导致apache工作者计数高？

我们有一个运行Apache2.4的遗留服务器集群，它运行我们的应用程序，位于ELB后面。此ELB有两个侦听器，一个HTTP和一个HTTPS，它们终止于ELB，并向其后面的实例发送常规HTTP流量。此ELB也已关闭预打开（它导致工作人员忙碌堆积）。在正常负载下，每个实例有1-3个忙碌的工作人员

我们有一个新的服务器集群，我们正试图迁移到一个新的ELB后面。此迁移的目的是允许SNI——服务于数千个域的TLS流量。因此，该集群使用已在ELB级别启用的mod_proxy_协议。为了进行测试，我们一直在DNS（路由53）级别对流量进行加权，以将30%的流量发送到新的负载平衡器。即使是在这样小的负载下，我们也会看到5-10个忙碌的工作人员，并且随着流量的增加而增加

作为进一步的测试，我们使用了其中一个新实例，禁用了proxy_协议，并将其从新的ELB移动到旧的ELB，工作人员计数下降到平均水平，即1-3个忙碌的工作人员。这似乎表明ELB（HTTP和TCP处理之间的差异？）或mod_proxy_协议存在问题

我的问题：为什么在使用代理协议和新的ELB时，我们有两倍于忙碌的apache工作人员？我认为，由于TCP侦听器是哑的，并且不对流量进行任何处理，因此它们会比HTTP侦听器更快，因此比HTTP侦听器消耗更少的工作时间，HTTP侦听器会主动“修改”通过它们的流量

---

我们非常感谢任何帮助我们诊断此问题的指导。

区别很简单，也很重要：

HTTP模式下的ELB负责保持来自浏览器的空闲保持活动连接，而不保持打开到实例的相应连接。浏览器连接和后端连接之间没有必要的关联——后端连接可以重用

在TCP模式下，它是1:1。这是必须的，因为ELB不能将后端连接重新用于前端的不同浏览器连接——它不能解释管道中的内容。这对于TCP来说总是正确的，但是如果原因不是直观的，那么在启用代理协议的情况下应该特别明显。

代理

“头”实际上不是通常意义上的“头”——它是一个前导。它只能在连接的最开始发送，标识源地址和端口。连接将一直保持，直到浏览器或服务器将其关闭或超时。现在是1:1

这在Apache中不太可能可行

返回HTTP模式一分钟

此ELB也已关闭预打开（它导致工作人员忙碌堆积）

我不知道你是怎么做到的——我从来没有看过文档，所以我想这一定是通过支持请求实现的

这似乎是一个解决完全错误问题的案例。在你看来，连接的数量不是人为地高，你真正做到的是人为地将连接的数量保持在较低的水平——最终，你可能实际上会削弱你的性能和扩展能力。这些备用连接用于处理突发需求。如果您的实例太小，无法处理它们，那么我建议真正的问题只是：您的实例太小

另一种方法——这正是我用于可怕的基于Apache的遗留应用程序的解决方案（其中一个应用程序有一个Apache服务器，位于总共15到20个不同的ELB后面——这是必要的，因为每个ELB都使用旧平台客户提供的证书卸载SSL）--是厄尔伯斯和阿帕奇之间的HAProxy。HAProxy每天可以在微小的实例上处理数百个连接和数百万个请求（我说的是tiny--t2.nano和t2.micro），并且它可以在每次请求后关闭Apache连接的同时保持所有ELB的连接处于活动状态。。。因此，它在两个方向上优化事情

---

当然，您也可以将HAProxy与TCP平衡器和代理协议一起使用——HAProxy的作者也是代理协议的创建者。您也可以在Apache实例上运行它，而不是在单独的实例上运行。它在内存和CPU方面是轻量级的，并且不会分叉。除了在Lua集成开发过程中偶尔提交错误报告之外，我与该项目没有任何关联。

感谢您的见解。当这样布置时，浏览器保持工作线程打开是非常有意义的，而ELB在执行HTTP路由时会减轻这一点。我们在ELB后面有大约18台服务器，并关闭了keep alive，因为我们认为在实例级别重用任何工作人员的连接的可能性很小。我们将按照建议查看HAProxy，我们还将重新评估处理连接重用的方式——如果您有任何建议，我们将非常乐意听取。此外：开放前的工作人员累积问题是通过支持票处理的。我们从未能够诊断出问题，因为我们没有时间投入，因为打开/关闭preopen需要支持票。当我们从EC2 classic迁移到VPC（同时从Apache2.2迁移到2.4）时，就发生了这种情况。VPC ELB导致工人在R“读取请求”状态下构建，很少关闭。最终，我们所有的工作人员都将处于R状态，Apache将开始拒绝进一步的流量，不管我们设置了多少max_工作人员。AWS支持人员和谷歌搜索都没有发现任何关于Apache无限期陷入“读取请求”的有趣信息。Apache应该关闭连接，或者ELB应该最终关闭它们（可能在超时之后）。HAProxy机器的标准配置使用

超时