Apache派生进程原理，event很给力
现在在编译新版glibc，虚拟机单核慢慢跑没什么事来说说Apache派生进程的原理。Apache在启动之后，除了最蛋疼的cgi模式在访问才fork进程外，如果使用的是CLI模式挂载php，可以用Apache的MPM来提升性能。在之前提到的Apache编译参数中官方对mpm提供了4个可选模式，分别是event|worker|prefork|winnt。winnt是给win用的故略过。
- prefork模式，每次访问都由单进程负责处理，配置文件中可以调整预派生的进程数量和可伸缩数量，会根据具体情况自动伸缩进程，如果求非常稳定，不想让一个访问出问题卡死全部的话，prefork是好选择。至于性能嘛，肯定排最后，我按倒序来排；
- worker由一个主进程事先派生一堆子进程，每个子进程下会有一堆线程并行处理请求，这个性能不用多说肯定秒杀prefork；
- event终于可喜可贺走出实验阶段，可以投入生产环境了。event是基于事件驱动的模式，网上一大堆资料都说这货在旧的阶段还不稳定呢o(╯□╰)o
官方的中文介绍只有2.2版本，我翻译一下2.4版本给出的工作原理介绍：
这个MPM模式适合用于在'keep alive'状态下的高并发请求，客户发起1次tcp连接后会使用该连接继续完成其它的http请求，节约了大量的tcp连接开销。但是Apache一直在使用整个子进程（译者注：这里指的是prefork）、线程（译者注：这里指的是worker）等待来自客户端的链接，这样也导致大量的资源开销。为了解决这个问题，这个MPM使用一个专用线程来处理监听socket，这个线程唯一的工作就是向保持keep alive状态的socket客户端发送数据。（译者注：感觉好别扭，难道是我理解错？）在mod_status状态页面可以看到现在的并发连接数。（译者注：也就是说其它线程只需要专心处理请求而不用考虑通讯这样来节约资源开销提高性能）
嘛。。随便翻译了下，应该更容易理解了。。
这个MPM尝试解决http1.1中的’长连接（保持会话）’问题。当一个客户端完成第一次请求后，这个客户可以叫我（Apache）Hold住链接（保持开启），然后呢这货就可以继续通过这个通道（这个socket）来发出请求。这样就可以节省由创建TCP链接带来的资源损耗了。
但是呢，我（Apache）会有一个非常严重的架构缺陷，即我（Apache）一般都会创建一个独立的线程/进程来监听客户端的数据。
总之呢，为了解决这个蛋疼的架构缺陷，所以我就弄了个新的MPM，也就是这玩意。这个MPM用了独立的线程同时处理和监听那些处于等待状态的客户，所以呢，当客户端再次发送数据的时候呢，这个线程仅仅需要返回处理过后的数据给客户（敢再啰嗦一点么），因为协议过滤器已经完成工作了。
当然，你也可以使用mod_stats模块来查看apache目前的处理情况（包括上述所有状态）
那啥，协议过滤器=握手