多处理模块(MPM)

Apache HTTP 服务器被设计为一个功能强大，并且灵活的 web 服务器， 可以在很多平台与环境中工作。不同平台和不同的环境往往需要不同的特性，或可能以不同的方式实现相同的特性最有效率。Apache httpd 通过模块化的设计来适应各种环境。这种设计允许网站管理员通过在 编译时或运行时，选择哪些模块将会加载在服务器中，来选择服务器特性。

Apache HTTP 服务器 2.0 扩展此模块化设计到最基本的 web 服务器功能。 它提供了可以选择的多处理模块(MPM)，用来绑定到网络端口上，接受请求， 以及调度子进程处理请求。

扩展到这一级别的服务器模块化设计，带来两个重要的好处:

• Apache httpd 能更优雅，更高效率的支持不同的平台。尤其是 Apache httpd 的 Windows 版本现在更有效率了，因为 mpm_winnt 能使用原生网络特性取代在 Apache httpd 1.3 中使用的 POSIX 层。它也可以扩展到其它平台 来使用专用的 MPM。
• Apache httpd 能更好的为有特殊要求的站点定制。例如，要求 更高伸缩性的站点可以选择使用线程的 MPM，即 worker 或 event； 需要可靠性或者与旧软件兼容的站点可以使用prefork。

在用户看来，MPM 很像其它 Apache httpd 模块。主要是区别是，在任何时间， 必须有一个，而且只有一个 MPM 加载到服务器中。

在全部平台中，MPM 都可以构建为静态模块。在构建时选择一种 MPM，链接到服务器中。如果要改变 MPM，必须重新构建。

为了使用指定的 MPM，请在执行 configure 脚本 时，使用参数 --with-mpm=NAME。NAME 是指定的 MPM 名称。

编译完成后，可以使用 ./httpd -l 来确定选择的 MPM。 此命令会列出编译到服务器程序中的所有模块，包括 MPM。

./httpd -l 和 ./httpd -V  选项都可以看出当前选用的 MPM 的模式

Apache的三种 MPM 模式

三种稳定的MPM（Multi-Processing Module，多进程处理模块）模式。它们分别是prefork，worker和event，三种模式在编译的时候，可以通过configure的参数来指定：

--with-mpm=prefork|worker|event

当然，也可以在编译时为三种都支持，通过修改配置来更换：

--enable-mpms-shared=all

这时，只需要在 httpd.conf 中修改 Apache 的多处理模式 MPM（modules文件夹下，会自动编译出三个MPM的so）：

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
#LoadModule mpm_event_module modules/mod_mpm_event.so

并在 httpd.conf 中添加 Include conf/extra/httpd-mpm.conf，httpd-mpm.conf 中包含了 MPM 的有关配置；

1、prefork MPM

prefork 模式可以算是很古老但是非常稳定的 Apache 模式。Apache 在启动之初，就预先 fork 一些子进程，然后等待请求进来。之所以这样做，是为了减少频繁创建和销毁进程的开销。每个子进程只有一个线程，在一个时间点内，只能处理一个请求。

1. 优点：成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。（我们常用的mod_php，PHP 的拓展不需要支持线程安全）
2. 缺点：一个进程相对占用更多的系统资源，消耗更多的内存。而且，它并不擅长处理高并发请求，在这种场景下，它会将请求放进队列中，一直等到有可用进程，请求才会被处理。

prefork 模式在 httpd-mpm.conf 中的默认配置：

<IfModule mpm_prefork_module>StartServers             5MinSpareServers          5MaxSpareServers         10MaxRequestWorkers      250MaxConnectionsPerChild   0
</IfModule>

2、worker MPM

worker 模式比起上一个，是使用了多进程和多线程的混合模式。它也预先 fork 了几个子进程（数量比较少），然后每个子进程创建一些线程，同时包括一个监听线程。每个请求过来，会被分配到 1 个线程来服务。线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，因为比起 prefork 有更多的可用线程，表现会更优秀一些。
    有些人会觉得奇怪，那么这里为什么不完全使用多线程呢，还要引入多进程？
    原因主要是需要考虑稳定性，如果一个线程异常挂了，会导致父进程连同其他正常的子线程都挂了（它们都是同一个进程下的）。为了防止这场异常场景出现，就不能全部使用线程，使用多个进程再加多线程，如果某个线程出现异常，受影响的只是 Apache 的一部分服务，而不是整个服务。

1. 优点：占据更少的内存，高并发下表现更优秀。
2. 缺点：必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用 keep-alive 的长连接方式，某个线程会一直被占据，也许中间几乎没有请求，需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在 prefork 模式下，同样会发生）

注：keep-alive 的长连接方式，是为了让下一次的 socket 通信复用之前创建的连接，从而，减少连接的创建和销毁的系统开销。保持连接，会让某个进程或者线程一直处于等待状态，即使没有数据过来。

worker 模式在 httpd-mpm.conf 中的默认配置：

<IfModule mpm_worker_module>StartServers             3MinSpareThreads         75MaxSpareThreads        250ThreadsPerChild         25MaxRequestWorkers      400MaxConnectionsPerChild   0
</IfModule>

3、event MPM

这个是 Apache 中最新的模式，在现在版本里的已经是稳定可用的模式。它和 worker 模式很像，最大的区别在于，它解决了 keep-alive 场景下，长期被占用的线程的资源浪费问题（某些线程因为被 keep-alive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。event MPM中，会有一个专门的线程来管理这些 keep-alive 类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。

event MPM 在遇到某些不兼容的模块时，会失效，将会回退到 worker 模式，一个工作线程处理一个请求。官方自带的模块，全部是支持 event MPM 的。

注意一点，event MPM 需要Linux系统（Linux 2.6+）对 EPoll 的支持，才能启用。

还有，需要补充的是 HTTPS 的连接（SSL），它的运行模式仍然是类似 worker 的方式，线程会被一直占用，知道连接关闭。部分比较老的资料里，说 event MPM 不支持 SSL，那个说法是几年前的说法，现在已经支持了。

event 模式在 httpd-mpm.conf 中的默认配置：

<IfModule mpm_event_module>StartServers             3MinSpareThreads         75MaxSpareThreads        250ThreadsPerChild         25MaxRequestWorkers      400MaxConnectionsPerChild   0
</IfModule>

生产环境 Apache MPM 优化

生产环境接入层硬件配置：

4 台 8 核 16G 内存阿里云 VPC ECS

实际压测统计 httpd 消耗内存大约每个 httpd 进程在 2M 左右：

[root@iZ23s96w2paZ ~]# ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Tot="sum"("n")";print "Avg="sum"/"n"="sum/n/1024"MB"}'
Tot=1106968(503)
Avg=1106968/503=2.23159MB

预留 5G 内存给 Apache 使用，同时为了避免在 apache 在 fork 进程等操作消耗，保留足够的工作进程，由于没有兼容性相关的测试，生产环境选用最原始的 profork 模式，配置如下：

<IfModule mpm_prefork_module>StartServers                 500ServerLimit                 2500MinSpareServers              500MaxSpareServers              1000MaxRequestWorkers            2000  MaxConnectionsPerChild       0
</IfModule>