MPM(多路处理模块)
event 模式
serverlimit 50 表示服务器允许开启的最大进程数量
startservers 初始开启进程 3
minsparethreads 最小闲置进程 5
maxsparethreads 最大闲置进程 10
apache必须要要保证有一定的闲置缓冲进程来给自己的访问负载留有后墙,一开始访问有2个进程占用(初始进程),那么闲置的进程就是1,为了保险起见万一别的人访问我留有后墙,apache规定了最小闲置进程就是5,那么apche父进程(root用户创建的父进程)第一秒增加1个进程数(闲置进程也叫子进程daemon用户创建),第二秒会增加2个进程数,第三秒会增加4个进程数,直到保证自己的闲置进程大于规定的minsparethreads5即可就停止增加,这是一个动态的过程,随着访问量增多,那么进程数会开的越来越多,直到很多人突然下线,潮水退去,那么假设最后我开启了100个进程,退了20个进程,那么是不是在那一瞬间20个进程限制,的确,满足了大于最小闲置进程数要求,但是万一100个全退,就是100个闲置进程,所以还有一个最大闲置进程,大于最大闲置进程我就关,反正闲置的进程,apache自己会运算反正后墙区间一定控制在最小闲置进程和最大闲置进程之间。
event工作模式最典型的方式是进程里面包裹多条线程,默认是25,真正执行代码的是线程,所以event工作模式适用处理于apache的高负载高并发情况下,而且event还有一个特点就是解决异步非租塞问题,什么意思呢,就是很多人连着这个网页,但是什么都不点都不请求就等着,一直占用那个keepalive保持连接,直到保持连接超时,这样一直占着就会导致资源浪费,event工作模式就是解决了这个问题,每个进程中都有一个keepalive线程去处理,处理我这个进程中客户端的keepalive挂着****那我来处理你,如果你访问鼠标点一点请求了,那么由同一进程中隔壁负责请求处理的正常线程去处理你,你点了一段时间又不点了,那么还是回到keepalive线程中 ,一个负责处理请求的线程对接一个客户端
maxrequestworkers 允许同一时间服务器同时响应工作的线程数量,一个线程对应一个客户端,超过请求数就会排队,比如apache运行了20个进程,每个进程运行24个服务线程,服务器可以同时进行24*20=480个并发的http请求,前480个都在线,你是第481个你可能就需要排队了哦,所以双十一为什么会排队,因为你的服务器线程就那么多,请求总有个上限限制,你网速不好,进去慢就要排队,所以最好的解决办法是网速要快,插网线带宽足够高用电脑抢,一直点,不用担心服务器死机,
maxconnnectionperchild 每个子进程在其生存周期内允许处理的最大http请求总数,设置为0就是这个进程永远不会停止,http请求没有上限,这样会消耗内存的资源,术语叫做php的内存泄漏,所有一般都会有个上限,比如到总数到20000结束,到了就在重新开一个进程
event模式优点:多进程,总有闲置进程,进程中多子线程,是进程中有线程处理http请求,并且有专门的线程处理keepalive客户端占据资源不访问题,可以实现和客户端不点击和点击的异步非阻塞,适用于高并发浏览量大的情况下开启此模式,进程开的少,都是进程里面有线程吗,所以内存占用比也会低一些
event模式条件:
需要linux操作系统支持epoll,2.6版本的linux都支持,多老才会不支持,
其次官方自带的模块event模式下的apache是兼容的,如果是第三方模块那可能得考虑一下了,event模式下的apache可能不支持
然后是https的连接,一个线程对应一个请求,安全性连接吗,如果处理https的连接会退回到worker模式,没有keepalive专门的线程去管不点击访问的客户端。
worker模式
worker模式的升级版就是event模式,不同之处在于进程中没有专门子线程去处理keepalive的保持连接,一个线程完完全全对接一个客户端,无法解决长连接资源被占用问题,无法实现服务线程和保持线程的异步非阻塞其余的没有任何区别。
event和worker的缺点:但worker和event也由不完善的地方,假如一个线程崩溃,整个进程就会连同其任何线程一起"死掉".由于线程共享内存空间,所以一个程式在运行时必须被系统识别为每 个线程都是安全的,不然容易出现多台客户端掉线的问题,严重些还会导致服务奔溃,而且很多php模块event模式也不支持。
prefork模式
prefork模式使用多个子进程,一个进程里面只有一个线程,在大多数平台上,prefork模式比worker和event模式更高效安全成熟速度快,因为一个进程奔溃不会影响其他线程其他客户端请求,而且正是一个进程处理一个线程,专门对接,高效迅速,不需要线程之间共享内存,所以有专门物理内存管理,内存大,不也快吗,其次不需要担心第三方模块的线程兼容性问题,apache在event工作模式下有的识别不了第三方模块,会退到work模式,所以对于一些中小型网站prefork模式更成熟稳定高效速度快
总结:比如,需要更好伸缩性的可以选择象worker或event这样线程化的MPM,而需要更好的稳定性和兼容性以适应一些旧的软件可以用prefork 。
event模式配置测试及ab压力测试
源码编译安装执行configure脚本时指定工作模式
如果在已经编译好切换,可以看出mpm配置文件三种模式都有,但是切换centos似乎很难,Redhat的切换方式如下
我们就以event模式配置为例吧,prefork这个最稳定的模式也是一样!
ab压力测试
apache没优化前
要注意一下,这个-n参数相当于是tcp的请求,一次就是相当于让多少个客户机去连接这个服务器,而这个-c相当于是httpd的并发请求,相当于一个客户端发出http请求数,所以最终的请求个数是n*c,这是测试服务器性能压力的有效方式
接下来我们来进行调优,初始进程调大,闲置子进程扩大,每个子进程的线程数增加,每个进程数允许处理的http请求数增加,我们来看一下服务器总计处理这些请求timetaken的处理时间
现实生活中用的很多压力性能测试工具都是第三方的,八九种,生产中apache自带的ab压测用的比较少,比较知名开源的的是LoadRunner、Apache JMeter等等
更好的理解prefork、worker、event具体链接如下
https://blog.51cto.com/13043516/2342574