三种MPM在工作时的属性_第1张图片

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

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

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

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


三种MPM在工作时的属性_第2张图片

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

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

image.png

通过上图我们会看到默认会启动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启动一个主进程,然后再通过主进程生成多个子进程,然后再通过子进程生成多个线程,每个线程负责一个请求,当然在配置文件当中会对主进程启动的子进程的个数、并发请求的最大数、最小空闲的线程数、最大空闲的线程数、每个子进程可生成的线程数、每个  子进程在生命周期内所能够服务的最多的请求个数做限定。