apache - 为什么 Apache 事件 MPM 表现不佳？

Question

Event MPM 与 Nginx 的设计并不完全相同，但显然旨在使 keepalive 更稳定并更快地发送静态文件。我的理解是事件 MPM 有点用词不当，因为:

1. 虽然连接传递给了kqueue/epoll，
2. 某些非常重要的模块，如 mod_gzip 和 mod_ssl 将阻塞/消耗一个线程，直到响应完成，
3. 这对于大文件来说是个问题，但对于 PHP 生成的 HTML 文档等可能不是。

不幸的是，Apache 不断失去市场份额，而且大多数基准测试都对事件 MPM 不利。基准测试是否存在缺陷，或者事件 MPM 对 Nginx 的表现真的很差？即使有这些限制，在正常流量(非恶意)和较小的文件下，它应该与 Nginx 具有一定的竞争力。例如，在慢速连接上通过 php-fpm 提供 PHP 生成的文档应该是有竞争力的，因为文档将被缓冲(即使是 ssl 和 gzip)并异步发送。使用压缩或不使用压缩的 SSL 和非 SSL 连接在这种工作负载上的工作方式不应与它们在 Nginx 中的工作方式有任何不同。

那么为什么它在各种基准测试中没有表现出色呢？它出什么问题了？或者基准有什么问题？主要网站是否使用它作为对它可以执行的权威的呼吁？

Answer 1

它比 nginx 慢，因为带有事件 MPM 的 Apache(非常)大致等同于带有 worker MPM 的 Apache 前面的事件驱动的 HTTP 代理(nginx、varnish、haproxy)。事件 是 工作人员，但事件 MPM 的线程不是将每个新连接都交给一个线程，而是将连接交给一个辅助线程，该线程将其推送到队列中，或者如果保持事件状态则将其关闭关闭或已过期。

event 相对于 worker 的真正好处是资源使用。如果您需要维持 1,000 个并发连接，工作 MPM 需要 1,000 个线程，而事件 MPM 可能需要 100 个事件线程和事件队列中管理的 900 个空闲连接。在那个假设中，事件 MPM 将使用 worker MPM 的一小部分资源，但缺点仍然存在:每个请求都由一个单独的线程处理，该线程必须由内核调度，因此会产生成本切换上下文。

另一方面，我们有 nginx，它使用事件模型本身作为其调度程序。 Nginx 只需在每个连接上处理尽可能多的工作，然后再继续下一个连接。不需要额外的上下文切换。

事件 MPM 真正发挥作用的一个用例是处理在 Apache 中运行的繁重应用程序的设置，并保存在保持事件期间空闲的线程资源，您可以部署一个代理(例如作为 nginx)在 apache 前面。如果您的前端没有其他用途(例如静态内容、代理到其他服务器等)，则事件 MPM 会漂亮地处理该用例并消除对代理的需要。