2.3.1 为什么需要MPM

老版本的NCSA server和Apache 1是在UNIX系统中成长起来的。当时Apache是一个多进程服务器，一个服务进程处理一个用户请求，如果当前并发客户访问数量大于服务进程数，Apache便会增加新的服务进程来处理当前请求。在正常情况下，Apache会维护一定数量的服务进程来处理用户的请求。

尽管这种多进程服务机制在Unix类系统中能够很好地工作，但是在其他的平台上效率却很低，如在Windows中产生一个进程是非常费时的。因此，让Apache真正实现跨平台还需要其他的方法。Apache 2采用的方法是把核心任务处理作为一个可插拔的模块，即MPM，使其能针对不同的环境进行优化。MPM架构允许不同的Apache模块在一个操作系统平台下共存，能够为用户根据不同应用做出选择。

在实际应用中，只有UNIX类操作系统有其他的选择，而其他系统平台（Windows、Netware、OS/2、BeOS）则只有唯一的根据操作系统优化的MPM。在UNIX平台上，Apache 2.2目前已经有两种高质量的、作为标准的MPM（Prefork和Worker），第三种（Eevent方式）在不使用SSL的情况下也是稳定可靠的。另外还有一些MPM可以实验应用，暂时不适合产品应用。其他第三方的MPM模块也是可用的。

2.3.2 UNIX类的MPM模块

Prefork MPM基于非线程模型，和Apache 1.x版本中的MPM很相似。Prefork MPM在所有情况下都很安全，对运行非线程安全（non-thread-safe）模式的软件如PHP，它是唯一的安全选择。对于某些应用程序，包括在Apache 1.3上非常流行的程序（如简单静态页面、CGI脚本等），Prefork MPM是最好的选择。

Worker MPM基于线程模式，具有内存消耗低（对繁忙的服务很重要）、扩展性在某些特定应用情况下比Prefork更好等优点。在稍后介绍SQL数据库支持和mod_dbd模块时我们会讨论其中一些内容。

以上两种稳定的MPM方式在非常繁忙的服务器应用下都有些不足。尽管HTTP的Keepalive方式能减少TCP连接数量和网络负载，但是Keepalive需要和服务进程或者线程绑定，这就导致一个繁忙的服务器会耗光所有的线程。Event MPM是解决这个问题的一种新模型，它把服务进程从连接中分离出来。在服务器处理速度很快，同时具有非常高的点击率时，可用的线程数量就是关键的资源限制，此时Event MPM方式是最有效的。一个以Worker MPM方式工作的繁忙服务器能够承受每秒好几万次的访问量（例如在大型新闻服务站点的高峰时），而Event MPM可以用来处理更高负载。值得注意的是，Event MPM不能在安全HTTP（HTTPS）访问下工作。

还有一些针对UNIX系统的、处于实验中的MPM，在本书编写过程中，它们在继续开发，有的可能已经实现了。Perchild MPM具有一个非常好的特性：以不用的用户ID为不同的虚拟主机运行Apache服务器。其他的一些MPM也提供类似的功能，包括第三方的Metux和Peruser，以及mod_ruid（只支持Linux）。为了运行外部程序，还可选择fastcgi/mod_fcgid和suexec（CGI）。作者对第三方的解决方案没有相应的了解，因此不能作出相应的评价。

2.3.3 MPM模块和操作系统

一言以蔽之：对应用程序来说，MPM方式很少见，应该忽略!

既然MPM内部机制不是应用程序接口的一部分，Apache的应用开发者不需要知道MPM的细节。这里就简单带过。一些为应用开发者提供的最佳实践的基本规则（命名机制、编写安全线程、交叉进程安全、代码重入）将会在第4章中简单介绍。这里主要介绍开发平台无关代码。事实上，有时应用程序的开发平台更要考虑MPM而不是操作系统。

有时一个应用程序更加适应于某个MPM。例如，数据库驱动或者负载均衡应用程序得益于thread MPM方式的连接池（在本书稍后讨论）。反之，产生子进程（原始的CGI实现或者mod_ext_filter）在一个基于线程的程序中会产生巨大开销，因此在Prefork MPM方式下工作得更好。然而，除非某些特殊限制，应用程序应该考虑如何适应在非首选的MPM下工作。

如果你想让Apache运行在现在还不支持Apache的操作系统上，那么首要的任务是在APR库中增加对目标平台的支持。APR库用来提供操作系统层的支持。一个定制的MPM不是必需的，但是它很可能比已有的MPM提供更好的性能。从Apache的角度出发，这

是一个系统编程的任务，因此它已经超出一本应用程序开发书籍的介绍范围。