我工作的地方我们的主要Web应用程序是使用nginx + uwsgi + Django。给定的生产箱上运行着80个uwsgi工作进程。我们的Django应用程序向Amazon S3发出了中等频率的请求，但是，如果这80个工作程序中的每一个都必须使用自己的HTTP连接来处理此类请求，那么它们就不足以利用（相对较短的）HTTP Keep-Alive允许的由亚马逊的服务器。因此，我们经常不得不在亚马逊方面断开连接后支付重新连接惩罚。
我想要的是，如果有一个代理服务在同一个盒子上运行，可以将这些80个进程的S3连接“集中”到一个较小的HTTP连接池中，这些连接可以充分利用它们将保持活动状态。 Django应用程序将连接到代理，代理将使用其保持活动连接池将请求转发到S3。我看到有可能使用nginx本身作为转发代理，但我不清楚它是否或如何利用我想到的连接池。理想的解决方案是擅长自动扩展，以便uwsgi工作人员永远不必等待代理本身进行连接，但会在负载下降时削减连接，以便尽可能保持连接“热”（也许）保持1或2备用以处理偶尔的上升）。
我遇到了其他正向代理，例如Squid，但这些产品似乎旨在实现更传统的缓存代理角色，例如用于拥有许多不同远程客户端的ISP。
是否有人知道此类问题的现有解决方案？非常感谢！