三种MPM在工作时的属性

l  prefork:域fork，一个进程一个请求

l  worker:一个线程一个请求，一个进程生成多个线程

l  event：事件模型，单线程响应多个请求，基于事件驱动

在主配置文件当中，在httpd程序启动时，会探测当前运行的是哪一种MPM模块，如果是prefork会怎样？如果是woker会怎样？如果是event会怎样？

NOTE:一个成熟的运维一定会对这一小节的内容倒背如流，如果连小节的内容都不能熟练记忆的话，说自己是运维就是诈骗,诈骗~

prefork的工作机制:httpd主程序会生成一个子进程来响应，自己负责侦听到套接字上，生成子进程需要按照自己复制一个，是需要时间的，等到请求来到之后再复制明显是来不及的，所以在进程没有到来之前其实就已经准备好了，一旦有请求进来就直接分配一个子进程响应，不用临时创建了，那么问题来了，预先创建多少个是好呢（最小空闲数）？要是一下子进来一千个，要准备1000个进程吗？一下子去退去之后子进程怎样办（最大空闲数）？回收多少呢？所以有规定：最大请求数，最大空闲数。规定最大请求数是因为prefork的工作机制是基于select事件分离器工作的，select的文件描述符最大也就是1024，也就是prefork引用1024个进程就已经是理论上限了，prefork是大之能同时处理1024个进程，实际上很可能达不到1024.平时如果没有请求是httpd主进程也要创建最小空闲数个空进程等待请求，如果一下子涌进500个请求，但事先只创建了200个空进程，在200个空进程没有用完之前就要再创建空进程。如果500个进程一下子都退去了，留下500个空进程回收时，保留最大的空闲数，余下的回收。如果一下子余下10000个请求，httpd有些无能为力，nginx可以。

通过上图我们会看到默认会启动4个进程，每个进程允许启动的线程数是25个，也就是说默认启动的线程数是4*25也就是100个，但是，但是，但是，你有没有注意到，还有一个参数就是MaxSpareThreads最大的空闲线程数是75个，所以默认会启动4个进程也就是100线程，100线程违反了最大空闲线程数，自己会杀掉25个线程，所以在我们看来，好像一会是3个进程，一会是4个进程。

worker的工作机制：一个主进程生成若干个子进程，每个子进程生成多个线程，每个线程响应一个请求，这是一种三级结构，那么每个子进程能够生成多少个线程呢？肯定有一个参数规定最大线程数的，假如说一个子进程可以生成25个线程，而每个线程响应一个请求，是不是性能比prefork要好的多呢？并不是这样的，因为每个进程里面的线程相互之间也要需要切换的，切换的多了，也是消耗性能的，而且，性能与prfork不分上下。

event的工作进程:基于事件驱动的机制，真正意义上实现了一个线程响应多个请求。event-driven(事件驱动)，主要目的在于实现单线程响应多个请求。

 

解释一下MAXRequestsPerChild，这个是每个子进程的生存周期，一个子进程服务完一个请求之后会被立刻杀死吗？可能会，如果服务完请求之后后面没有请求后可能会被杀死，但是不一定，如果这个进程默认启动的最小空闲进程当中的一个的话还不会杀死，如果后面还有请求的话，httpd的主机进程肯定不会把此子进程给干掉的，因为干掉之后还要重新创建一个子进程来响应，现在有一个现成的，实在是犯不上！！所以这个子进程会被继续使用，这个子进程不断被重复使用会一个次数，这里定义的4000其实就是这个子进程被重复使用的次数，超过个次数之后就会被干掉，然后重新生成一个。

worker是三级结构，肯定会通过root启动一个主进程，然后再通过主进程生成多个子进程，然后再通过子进程生成多个线程，每个线程负责一个请求，当然在配置文件当中会对主进程启动的子进程的个数、并发请求的最大数、最小空闲的线程数、最大空闲的线程数、每个子进程可生成的线程数、每个  子进程在生命周期内所能够服务的最多的请求个数做限定。