☰

针对大型并发请求和静态文件优化 Apache

tag-icon • tag-icon apache-2.2 scalability concurrency
针对大型并发请求和静态文件优化 Apache

好的，我知道我问的问题之前已经被问过多次了（例如这里 - 提供数百万个并发连接和静态文件？），但好像没有具体的解决办法，所以我想再问一下，请大家耐心等待。

我们可以为此使用 nginx，但出于多种原因，我们使用 Apache（例如熟悉 Apache、保持堆栈一致、日志格式化等）。

我们正在尝试使用 Apache 来处理大量静态文件的并发请求。这应该简单直接，特别是因为静态文件是小图像，但 Apache 似乎不能很好地处理这一点。

更具体地说，当 Apache 看到每秒近 100 个并发（同时）请求时，Apache 似乎在 Amazon EC2 m1.medium 盒（4 GB RAM + 1 个核心，2 个超线程）上崩溃。（此时，该盒本身似乎正在处理更多连接 -netstat -n |复制代码复制代码厕所显示 250+ 个连接。

最大的问题是静态内容请求有时需要 5-10 秒才能得到满足，这会给我们的最终用户带来糟糕的用户体验。

我们是不是RAM/内存受限 - 正在运行免费-m显示以下内容：

             total       used       free     shared    buffers    cached
Mem:          3754       1374       2380          0        139       332
-/+ buffers/cache:        902       2851
Swap:            0          0          0

我们能否进一步优化 Apache，使其能够处理更多同时连接并更快地提供静态内容？拥有更多 RAM 或 CPU 是否有帮助（即使它们似乎未得到充分利用）。

或者可能存在一些我们忽略的其他完全不同的问题？

答案1

我们最终能够解决这个问题，并使用 Apache 本身将响应时间从几秒缩短到几毫秒。

问题不在于 Apache，而在于默认的 MaxClients 设置导致了问题。我们提高了 MaxClients/ServerLimit 设置，Apache 能够出色地处理大量并发请求并传输静态文件，而内存使用量仅略有增加。（我们花了一段时间才发现这一点，因为我们使用 ApacheBench 进行压力测试，但它无法让我们准确了解发生了什么。）

我们仍在使用 prefork MPM，但将来也可能会考虑使用 worker 和 event MPM。不过目前我们对 prefork MPM 的性能非常满意。

这是一篇很好的参考文章：apache 中的 MaxClients。如何知道我的进程的大小？

相关内容