22

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

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

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

那么为什么它没有在各种基准测试中大放异彩呢？它出什么问题了？或者基准有什么问题？一个主要网站是否使用它来呼吁它可以执行的权威？

4

2 回答 2

18

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

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

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

事件 MPM 真正大放异彩的一个用例是处理在 Apache 中运行的繁重应用程序的设置，并为了节省保持活动期间空闲的线程资源，您将部署代理（例如 nginx）在阿帕奇面前。如果您的前端没有其他用途（例如静态内容、代理到其他服务器等），事件 MPM 可以很好地处理该用例并消除对代理的需求。

于 2015-01-14T21:40:55.527 回答
7

对我来说，主要的操作差异是：

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

这就是为什么像 nginx（或 Apache Traffic Server 或任何现代商业/高性能代理）这样的高容量服务器通常会领先。

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

但我也不认为它表现得如此糟糕，除了最极端的工作负载或极其受限的系统之外。由于某种原因，我见过的大多数基准测试质量都非常差。

我认为大多数人希望他们今天所谓的网络服务器成为更复杂的应用程序服务器（Java EE、PHP 等）的代理，并且旨在最有效地移动 I/O 而没有 API 包袱的服务器将具有优势.

于 2015-01-13T01:46:43.730 回答