为什么不能总是使用Apache的事件MPM而不是工作进程MPM？

Question

为什么不能总是使用Apache的事件MPM而不是工作进程MPM？

6

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

在高并发、无 SSL 环境中，如果 KeepAlive 超时时间很长，我认为 mpm_event 有潜力使系统可以使用相同的资源承载更高的工作负载，而不使用 mpm_worker 的系统。更重要的是，从资源使用和功能方面来看，mpm_event 在所有情况下至少与 mpm_worker 同等甚至更好。

尽管我理解 mpm_event 总是至少与 mpm_worker 相当甚至更好，但我的最爱 Linux 发行版在安装 Apache 2.4 时默认使用 mpm_worker。这让我想知道是否我考虑不全面，是否有一些技术上的原因我没有使用 mpm_event 而是在 Apache 2.4 中使用 mpm_worker。

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

- user636044

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- covener · Accepted Answer

我能想到两个“优点”。两者都相当晦涩。

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

其次，在某些非常晦涩的第三方模块中，在事件下可能存在微妙的错误，例如异步写完成意味着某些回调发生在“不同”的线程上。异步写完成是指当向客户端的写入会阻塞（客户端读取缓慢）时，请求将被暂停，并在客户端套接字再次可写时在新线程上重新启动。