事件MPM与Nginx的设计并不完全相同，但显然是为了使Keepalive更持久，并更快地发送静态文件而设计的。我的理解是，事件MPM有点用词不当，因为:
不幸的是，Apache一直在失去市场份额，并且大多数基准测试都在对该事件MPM进行指责。基准测试是否存在缺陷，或者MPM对Nginx的确表现不佳？即使有这些限制，在正常流量(非恶意)和较小文件的情况下，它也应与Nginx竞争。例如，在慢速连接上通过php-fpm提供服务来生成PHP生成的文档应该具有竞争力，因为该文档将被缓冲(即使是ssl和gzip)并异步发送。无论使用压缩还是不使用压缩，SSL和非SSL连接的工作方式都不应与在这种工作负载下的Nginx有意义地不同。
那么，为什么它在各种基准测试中不发光呢？它出什么问题了？还是基准测试出了什么问题？一个主要站点是否使用它来吸引它可以执行的权限？
最佳答案
它比nginx慢，因为具有事件MPM的Apache大约(非常)等效于具有工作人员MPM的Apache前面的事件驱动的HTTP代理(nginx，清漆，haproxy)。事件是工作程序，但事件MPM的线程并没有将每个新的连接移交给一个线程，而是将其移交给一个辅助线程，该线程将其插入队列或在保持 Activity 关闭或过期时将其关闭。
事件优于工作程序的真正好处是资源使用情况。如果您需要维持1,000个并发连接，则辅助MPM需要1,000个线程，而事件MPM可以通过事件队列中管理的100个 Activity 线程和900个空闲连接来解决。在这种假设下，事件MPM将使用 worker MPM的资源的一小部分，但缺点仍然存在:每个请求都由单独的线程处理，该线程必须由内核调度，因此会产生成本。切换上下文。
另一方面，我们有nginx，它使用事件模型本身作为其调度程序。 Nginx会在继续进行下一个连接之前，尽可能简单地在每个连接上处理尽可能多的工作。无需额外的上下文切换。
MPM事件真正发挥作用的一个用例是处理一个有大量应用程序在Apache中运行的设置，并保存在保持 Activity 状态期间空闲的线程资源，您将部署一个代理(例如nginx)在 Apache 面前。如果您的前端没有其他用途(例如，静态内容，到其他服务器的代理等)，则事件MPM可以很好地处理用例并消除对代理的需求。
关于apache - 为什么Apache Event MPM的表现不佳？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/27856231/