为什么Apache Event MPM表现不佳？

Question

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

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

不幸的是，Apache一直在失去市场份额，而且大多数基准都是对MPM这个事件的诅咒。基准测试是否存在缺陷，或者事件MPM对Nginx的影响是否真的如此糟糕？即使有这些限制，在正常流量（非恶意）和较小的文件下，它应该与Nginx有一定的竞争力。例如，它应该具有竞争力，可以通过php-fpm在慢速连接上提供PHP生成的文档，因为文档将被缓冲（即使是ssl＆＃39; d和gzip＆＃39; d）并且是异步发送的。使用压缩或不使用压缩的SSL和非SSL连接的工作方式与Nginx在此类工作负载上的工作方式不同。

那为什么它不会在各种基准测试中闪耀？它有什么问题？或者基准测试有什么问题？是一个主要网站使用它作为对权威的诉求吗？

Answer 1

它比nginx慢，因为带有事件MPM的Apache（非常）大致相当于Apache与工作者MPM之前的事件驱动的HTTP代理（nginx，varnish，haproxy）。事件是工作者，但是事件MPM的线程将连接交给一个辅助线程，将其推送到队列或者如果keep-alive是关闭它，而不是将每个新连接交给一个线程。关闭或已过期。

事件超过工人的真正好处是资源使用。如果需要维持1,000个并发连接，则worker MPM需要1,000个线程，而事件MPM可能会在事件队列中管理100个活动线程和900个空闲连接。事件MPM将在该假设中使用工作者MPM的一小部分资源，但缺点仍然存在：每个请求都由一个必须由内核调度的单独线程处理，因此将产生转换背景。

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

事件MPM真正发挥作用的一个用例是处理在Apache中运行繁重应用程序的设置，并且为了节省在保持活动期间空闲的线程的资源，您将部署代理（例如作为nginx）在apache面前。如果您的前端没有其他用途（例如静态内容，代理到其他服务器等等），则事件MPM处理该用例精美并且无需代理。

Answer 2

对我来说，主要的操作差异在于：事件：

• 处理程序（负责生成响应的插件）是同步的 - 如果它们执行计算或I / O，它们将占用一个线程
• 核心必须使用跨线程锁来保护关键数据结构，因为它是多线程的，以支持这么多的同步请求

这就是为什么在非常大量的服务器上，例如nginx（或Apache Traffic Server或任何现代商业/高性能代理）通常会出现。

IMO你问题中的项目符号有点偏僻，SSL和deflate对这里的差异并没有太大贡献，因为它们都是过滤器，它们并没有真正导致可扩展性问题，甚至将httpd与传统的API联系起来保证请求或连接的生命周期。像这样的过滤器（与处理程序或负责低级I / O的核心过滤器）可能是与处理模型相关的最少的东西。

但是，除了最极端的工作负载或极端受限的系统之外，我还认为它的表现并不如此差。由于种种原因，我见过的大多数基准都质量极差。

我认为很大程度上人们希望他们今天所谓的网络服务器能够成为更复杂的应用服务器（Java EE，PHP等）的代理服务器，并且设计用于在没有API行李的情况下最有效地移动I / O的服务器将会有优势。