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

Question

mpm_event 与mpm_worker 类似，只是mpm_event 使用单独的专用线程管理所有（非 SSL）KeepAlive 连接，而不是让每个线程管理每个单独的连接。通过为每个 KeepAlive 连接提供并保留一个专用线程，mpm_worker 使该线程及其资源绑定到该连接，而不管是否正在处理请求。另一方面，mpm_event 通过允许线程及其资源在请求完成后回收回系统来降低高并发环境中的系统资源使用率。

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

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

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

Answer 1

我能想到两个“优势”。两者都很晦涩。

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

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