Apache MPM事件

与工人MPM的关系

event基于workerMPM，它实现了混合多进程多线程服务器。单个控制进程（父进程）负责启动子进程。每个子进程都会按照指令中的指定创建固定数量的服务器线程ThreadsPerChild，以及一个侦听器线程，该线程侦听连接并将连接到达时将其传递给工作线程进行处理。

运行时配置指令与所提供的指令相同worker，只是增加了AsyncRequestWorkerFactor。

怎么运行的

该MPM尝试修复HTTP中的“保持活动状态”。客户端完成第一个请求后，它可以保持连接打开，使用同一套接字发送其他请求，并节省创建TCP连接的大量开销。但是，Apache HTTP Server传统上会保留整个子进程/线程来等待来自客户端的数据，这有其自身的缺点。为了解决此问题，此MPM为每个进程使用专用的侦听器线程来处理侦听套接字，处于保持活动状态的所有套接字，处理程序和协议过滤器已完成工作的套接字以及仅剩余的套接字要做的就是将数据发送到客户端。

这种新的架构利用了无阻塞套接字和APR公开的现代内核功能（例如Linux的epoll），不再需要对其进行mpm-accept Mutex 配置，以避免出现雷电群问题。

单个进程/线程块可以处理的连接总数由AsyncRequestWorkerFactor指令控制。

异步连接

异步连接将需要一个固定的专用工作线程与先前的MPM，但不需要事件。的状态页mod_status在“异步连接”部分下显示新列：

写作

在将响应发送到客户端时，可能会由于连接速度太慢而导致TCP写缓冲区填满。通常在这种情况下，在空闲时间之后write()，套接字的a返回EWOULDBLOCK或EAGAIN再次变为可写状态。持有套接字的工作程序可能能够将等待的任务卸载到侦听器线程，从而一旦套接字发生事件（例如，“套接字已现在可写”）。请检查“限制”部分以获取更多信息。

活着

“保持活动”处理是工作者MPM的最基本改进。一旦工作线程完成将响应刷新到客户端的操作，就可以将套接字处理工作分流到侦听器线程，从而依次等待来自OS的任何事件，例如“套接字可读”。如果客户端有任何新请求，则侦听器会将其转发到可用的第一个工作线程。相反，如果KeepAliveTimeout发生这种 情况，则监听器将关闭套接字。这样，工作线程不负责空闲套接字，并且可以将它们重新用于服务其他请求。

闭幕

有时，MPM需要执行持久的关闭，即在仍将数据传输到httpd的同时，将早期错误发送回客户端。发送响应然后立即关闭连接不是正确的操作，因为客户端（仍然尝试发送其余请求）将重置连接并且无法读取httpd的响应。持续的关闭是有时间限制的，但是可能会花费相对较长的时间，因此将其卸载到工作线程（包括关闭挂钩和实际套接字关闭）中。从2.4.28开始，连接最终超时时也是如此（侦听器线程除了等待并调度其事件外，从不处理连接）。

这些改进对HTTP / HTTPS连接均有效。

流畅地终止流程和使用记分板

该MPM过去显示了一些可伸缩性瓶颈，导致出现以下错误：“计分板已满，而不是在MaxRequestWorkers处 ”。 MaxRequestWorkers 限制在任何给定时间将服务的并发请求数，以及允许的进程数（MaxRequestWorkers / ThreadsPerChild）；同时，记分板表示所有正在运行的进程及其工作线程的状态。如果记分板已满（因此所有线程都处于非空闲状态），但服务的活动请求数不是MaxRequestWorkers，则意味着其中一些正在阻止可以服务但正在排队的新请求（最多施加的限制 ListenBacklog）。在大多数情况下，线程都处于Graceful状态，即它们正在等待通过TCP连接完成其工作，以安全地终止并释放记分板插槽（例如，处理长时间运行的请求，慢速客户端或与保持活动状态）。两种情况很常见：

• 在正常重启期间，父进程会发信号通知其所有子进程完成其工作并终止，同时重新加载配置并派生新进程。如果大一点的孩子在停下来之前继续跑步一段时间，记分板将被部分占用，直到他们的插槽被释放。
• 服务器负载的下降会导致httpd停止某些进程（例如由于 MaxSpareThreads）。这特别有问题，因为当负载再次增加时，httpd将尝试启动新进程。如果重复这种模式，则进程的数量可能会增加很多，最终导致尝试停止的旧进程和尝试执行某些工作的新进程混合在一起。

从2.4.24开始，mpm-event变得更智能，并且能够以更好的方式处理正常终止。一些改进是：

• 允许使用所有记分牌插槽（最多） ServerLimit。 MaxRequestWorkers并 ThreadsPerChild用于限制活动进程的数量；同时， ServerLimit 还应考虑进行适当的关闭以在需要时允许额外的插槽。这个想法是用来 ServerLimit在影响系统资源之前，指示httpd允许多少个总体过程。
• 强制优雅地完成进程以使其处于保持活动状态以关闭其连接。
• 在正常关闭期间，如果给定进程的运行中的工作线程多于打开的连接，请终止这些线程以更快地释放资源（新进程可能需要）。
• 如果记分板已满，请防止由于负载减少而导致更多进程正常完成，直到旧进程终止为止（否则，一旦负载再次增加，情况将变得更糟）。

最后一点中描述的行为可以通过mod_status连接摘要表中的两个新列完全 看到：“插槽”和“停止”。前者指示PID，后者指示过程是否停止；多余的状态“是（旧生成）”表示正常重启后进程仍在运行。

局限性

对于已声明自己与事件不兼容的某些连接过滤器，改进的连接处理可​​能不起作用。在这些情况下，该MPM将退回到MPM的行为 worker并为每个连接保留一个工作线程。服务器随附的所有模块均与事件MPM兼容。

当前，对于涉及需要读取和/或修改整个响应主体的输出过滤器的请求，存在类似的限制。如果在过滤器处理数据时阻塞了与客户端的连接，并且过滤器产生的数据量太大而无法在内存中进行缓冲，则在httpd等待挂起的数据被释放时，不会释放用于请求的线程。发送给客户。
为了说明这一点，我们可以考虑以下两种情况：提供静态资产（如CSS文件）与提供从FCGI / CGI或代理服务器检索的内容的服务。前者是可以预见的，即事件MPM在内容末尾具有完全可见性，并且可以使用事件：提供响应内容的辅助线程可以刷新第一个字节，直到EWOULDBLOCK 或EAGAIN返回，将其余的委托给侦听器。这依次等待套接字上的事件，并委派工作将其余的内容刷新到第一个空闲的工作线程。同时，在后一个示例（FCGI / CGI /代理内容）中，MPM无法预测响应的结束，并且工作线程必须先完成其工作，然后才能将控件返回给侦听器。唯一的选择是将响应缓冲在内存中，但是出于服务器稳定性和内存占用的考虑，这不是最安全的选择。

背景材料

通过在支持的操作系统中引入新的API，使事件模型成为可能：

• epoll（Linux）
• kqueue（BSD）
• 事件端口（Solaris）

在提供这些新API之前，必须使用传统API select和pollAPI。如果用于处理许多连接或连接变化率很高，则这些API会变慢。新的API允许监视更多的连接，并且在一组监视频繁变化的连接时，它们的性能更好。因此，这些API使得编写事件MPM成为可能，该事件可通过许多空闲连接的典型HTTP模式进行更好地扩展。

MPM假定基础apr_pollset 实现是合理的线程安全的。这使MPM可以避免过多的高级锁定，也不必唤醒侦听器线程才能向其发送保持活动套接字。当前仅与KQueue和EPoll兼容。

要求

该MPM依赖于APR的原子比较和交换操作来进行线程同步。如果要编译支持x86的目标，你不需要支持386，或者你正在编译为SPARC，你不需要在UltraSPARC之前芯片上运行，添加 --enable-nonportable-atomics=yes到 configure脚本的参数。这将导致APR使用旧式CPU中不可用的有效操作码来实现原子操作。

该MPM在缺少良好线程的较旧平台上的性能不佳，但是对于EPoll或KQueue的要求使得此问题无济于事。

• 要在FreeBSD上使用此MPM，建议使用FreeBSD 5.3或更高版本。但是，如果您使用的话，可以在FreeBSD 5.2.1上运行该MPM libkse（请参阅参考资料man libmap.conf）。
• 对于NetBSD，建议至少使用2.0版。
• 对于Linux，建议使用2.6内核。还需要确保glibc已编译了您的EPoll版本。

ThreadsPerChild = 10
ServerLimit = 4
AsyncRequestWorkerFactor = 2
MaxRequestWorkers = 40

idle_workers = 4 (average for all the processes to keep it simple)

max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
                = (10 + (2 * 4)) * 4 = 72

ThreadsPerChild = 10
ServerLimit = 4
MaxRequestWorkers = 40
AsyncRequestWorkerFactor = 2

idle_workers = 10

max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
                = (10 + (2 * 10)) * 4 = 120

max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
                = (2 + 1) * 40 = 120