apache - 为什么不应该总是使用 Apache 的事件 MPM 而不是工作 MPM？

Question

mpm_event就像 mpm_worker除了 mpm_event使用单独的专用线程管理所有(非 SSL)KeepAlive 连接，而不是让每个线程管理每个单独的连接。通过为每个 KeepAlive 连接提供并保留一个专用线程，mpm_worker无论是否正在处理请求，都会将该线程及其资源绑定(bind)到该连接。 mpm_event另一方面，可以通过在请求完成后允许线程及其资源回收回系统来降低高并发环境中的系统资源使用。

在我看来，在 KeepAlive 超时时间较长的高并发、非 SSL 环境中，mpm_event与使用 mpm_worker 的系统相比，具有相同资源的系统有可能使用同等资源处理更高工作负载的系统。 . 更重要的是，在我看来，在资源使用和功能方面，mpm_event至少和 mpm_worker 一样好，如果不是更好，在所有情况下。

尽管我理解 mpm_event总是至少一样好，可能更好，我最喜欢的 Linux 发行版默认使用 mpm_worker从存储库安装 Apache 2.4 时。这让我想知道我的想法是否不完整，是否有一些技术原因我缺少使用 mpm_worker而不是 mpm_event在 Apache 2.4 中。

因此，我的问题是我说 mpm_worker 是否正确？至少和 mpm_event 一样好，如果不是更好，在所有情况下，以及 (2) 如果不是，使用 mpm_worker 有什么技术优势？在 Apache 2.4 中？

Answer 1

我能想到两个“优点”。两者都非常晦涩难懂。

worker 不需要在每个进程中争夺一个锁来保护保活连接列表。这意味着退化的工作负载可能会在相对较低的客户端总数中看到锁争用，因此根本无法从事件的可伸缩性中受益。

其次，一些非常晦涩的第三方模块可能在事件下存在细微的错误，例如异步写入完成意味着一些回调发生在“不同”线程上。异步写入完成是当对客户端的写入阻塞(客户端读取缓慢)时发生的情况，因此请求被挂起，当客户端套接字再次可写时，将在新线程上恢复生命。