最近在了解webman关于优化Linux内核的内容,里面提到了在这个优化基础之前,需要开启event扩展。此前有了解到IO多路复用里面的几种模式,于是想通过实际的测试,来看下开启event扩展之后实际的提升有多大。
在起初,直接本地搭建环境。通过相同的镜像(这里借助了tinywan/docker-php-webman的镜像)构建了两个容器,两个容器都设置了linux内核优化的相关参数。然后一个开启event扩展一个未开启,然后通过宿主机去压测,两边压测结果都没啥区别,于是想到有可能是因为宿主机自身的并发数限制,于是决定直接在阿里云上搞。
受压端与施压端保证同一个可用区,通过内网压测,机型选择的是通用算力型,避免用共享型机器,系统均是Debian
受压端:2核(vCPU) 2 GiB
施压端:8核(vCPU) 8 GiB
安装PHP8.0,搭建webman,设置linux 内核,其中linux设置内核生效的有以下几项
设置打开文件数
关闭event扩展
开启event扩展
压测接口
官方自带示例接口/index/json
设置linux内核
设置文件打开数
安装 Apache的ab工具
压测命令
ab -n 2000000 -c 5000 -k http://172.18.155.51:8787/index/json
受压端CPU状态
施压端CPU状态
压测失败
压测结束,这里受压端还一直持有connection,估计是因为压测端的异常断开
缩小并发数
ab -n 2000000 -c 1500 -k -r http://172.18.155.51:8787/index/json
QPS压测结果:
67065.64
66931.87
66882.92
压测命令
ab -n 2000000 -c 1500 -k http://172.18.155.51:8787/index/json
受压端CPU状态
施压端CPU状态
3次QPS压测结果:
66183.54
64454.47
66645.59
增高并发数
ab -n 2000000 -c 5000 -k -r http://172.18.155.51:8787/index/json
受压端
压测结果
受压端保持两个worker
不开启event与开启event表现基本一致
场景 | 压测一 | 压测二 | 压测三 |
---|---|---|---|
不开启event | 67065 | 66931 | 66882 |
开启event | 66183 | 64454 | 66645 |
不开启event,施压端出现报错
apr_pollset_poll: The timeout specified has expired
开启event,压测正常
并发数超5000,开启event能正常受理,这个能够理解。
但是按照两种多路复用的模型,epoll的方式在性能上不应该比select上更加出色吗,为啥两者在并发数1500的时候,表现出来的性能却是差不多的?
@walkor walkor或者其他同学了解这块看到的话,能帮忙解答一下疑问么🤔
大佬这个命令行工具是什么啊 看着不错
😂看起来这个shell客户端比我提的问题更有吸引力
XTerminal,https://www.xterminal.cn/
虽然我也用这个工具,但是
epoll是为解决Linux内核处理[大量]文件描述符而提出的方案
但是除了解决大量文件描述符,从它改进的思路来看,从select的轮询变为epoll的回调,两者在调用的触发思路上应该也有区别呀
epoll要维持一个RB树和多个等待队列,内核开销很大,FD少的时候,底层开销得不偿失
select监听的fd数量较少,fd就绪所消耗的时间复杂度就会大大减小
所以如果我切换成大量并发的话应该能看出效果,但是因为ab压测不成功(设置并发数5000,select模式下压测报错),所以反而看不出具体结果
是这样理解么?
有点明白了,谢谢walkor
对了,在压测过程中发现个另外的问题
在select场景下,并发数过高时,我看到worker下的tcp连接全是close_wait状态,一直不会释放。
webman版本v1.5.10
正常,select最多处理1024个连接,超出部分无法响应,无法检测到连接关闭,连接就一直处于close_wait
你终端叫什么名字
XTerminal,https://www.xterminal.cn/
好吧 不敢用,好像个人开发的
个人,还在开发阶段
梳理了一下select和epoll的内部实现,欢迎指正
https://blog.jeyfang.com/archives/574