为什么ApacheEventMPM表现不佳？

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

虽然连接传递给kqueue/epoll,

某些非常重要的模块,如mod_gzip和mod_ssl,将阻塞/使用一个线程,直到响应完成,

这对于大型文件来说是一个问题,但可能不适用于PHP生成的HTML文档等.

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

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

它比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)在阿帕奇面前.如果您的前端没有其他用途(例如静态内容,代理到其他服务器等等),MPM事件可以很好地处理该用例并且无需代理.

对我而言，主要的手术差异在于：

处理程序（负责生成响应的插件）是同步的-如果它们执行计算或I / O，它们将占用线程

内核必须使用跨线程锁来保护关键数据结构，因为它是多线程的，以支持许多此类同步请求

这就是为什么在大批量交易中，诸如nginx（或Apache Traffic Server或任何现代商业/高性能代理）之类的服务器通常会领先的原因。

IMO您问题中的项目符号有点离谱，SSL和deflate并没有真正为此处的差异做出太大贡献，因为它们都是过滤器，它们并没有真正导致可伸缩性问题，甚至没有将httpd与其传统的API保证相关联请求或连接的生命周期。此类过滤器（与处理程序或负责低级I / O的核心过滤器相比）可能是与处理模型联系最少的东西。

但我也认为，除了最极端的工作负载或极为受限制的系统之外，对于所有其他产品而言，它的性能都不会如此差。由于某种原因，我见过的大多数基准测试质量都很差。

我认为大部分人都希望今天所谓的Web服务器成为更复杂的应用程序服务器（Java EE，PHP等）的代理，而旨在最高效地移动I / O而又不占用API的服务器将具有优势。