最近在了解webman關(guān)于優(yōu)化Linux內(nèi)核的內(nèi)容,里面提到了在這個優(yōu)化基礎(chǔ)之前,需要開啟event擴(kuò)展。此前有了解到IO多路復(fù)用里面的幾種模式,于是想通過實際的測試,來看下開啟event擴(kuò)展之后實際的提升有多大。
在起初,直接本地搭建環(huán)境。通過相同的鏡像(這里借助了tinywan/docker-php-webman的鏡像)構(gòu)建了兩個容器,兩個容器都設(shè)置了linux內(nèi)核優(yōu)化的相關(guān)參數(shù)。然后一個開啟event擴(kuò)展一個未開啟,然后通過宿主機(jī)去壓測,兩邊壓測結(jié)果都沒啥區(qū)別,于是想到有可能是因為宿主機(jī)自身的并發(fā)數(shù)限制,于是決定直接在阿里云上搞。
受壓端與施壓端保證同一個可用區(qū),通過內(nèi)網(wǎng)壓測,機(jī)型選擇的是通用算力型,避免用共享型機(jī)器,系統(tǒng)均是Debian
受壓端:2核(vCPU) 2 GiB
施壓端:8核(vCPU) 8 GiB
安裝PHP8.0,搭建webman,設(shè)置linux 內(nèi)核,其中l(wèi)inux設(shè)置內(nèi)核生效的有以下幾項
設(shè)置打開文件數(shù)
關(guān)閉event擴(kuò)展
開啟event擴(kuò)展
壓測接口
官方自帶示例接口/index/json
設(shè)置linux內(nèi)核
設(shè)置文件打開數(shù)
安裝 Apache的ab工具
壓測命令
ab -n 2000000 -c 5000 -k http://172.18.155.51:8787/index/json
受壓端CPU狀態(tài)
施壓端CPU狀態(tài)
壓測失敗
壓測結(jié)束,這里受壓端還一直持有connection,估計是因為壓測端的異常斷開
縮小并發(fā)數(shù)
ab -n 2000000 -c 1500 -k -r http://172.18.155.51:8787/index/json
QPS壓測結(jié)果:
67065.64
66931.87
66882.92
壓測命令
ab -n 2000000 -c 1500 -k http://172.18.155.51:8787/index/json
受壓端CPU狀態(tài)
施壓端CPU狀態(tài)
3次QPS壓測結(jié)果:
66183.54
64454.47
66645.59
增高并發(fā)數(shù)
ab -n 2000000 -c 5000 -k -r http://172.18.155.51:8787/index/json
受壓端
壓測結(jié)果
受壓端保持兩個worker
不開啟event與開啟event表現(xiàn)基本一致
場景 | 壓測一 | 壓測二 | 壓測三 |
---|---|---|---|
不開啟event | 67065 | 66931 | 66882 |
開啟event | 66183 | 64454 | 66645 |
不開啟event,施壓端出現(xiàn)報錯
apr_pollset_poll: The timeout specified has expired
開啟event,壓測正常
并發(fā)數(shù)超5000,開啟event能正常受理,這個能夠理解。
但是按照兩種多路復(fù)用的模型,epoll的方式在性能上不應(yīng)該比select上更加出色嗎,為啥兩者在并發(fā)數(shù)1500的時候,表現(xiàn)出來的性能卻是差不多的?
epoll是為解決Linux內(nèi)核處理[大量]文件描述符而提出的方案
但是除了解決大量文件描述符,從它改進(jìn)的思路來看,從select的輪詢變?yōu)閑poll的回調(diào),兩者在調(diào)用的觸發(fā)思路上應(yīng)該也有區(qū)別呀
epoll要維持一個RB樹和多個等待隊列,內(nèi)核開銷很大,FD少的時候,底層開銷得不償失
select監(jiān)聽的fd數(shù)量較少,fd就緒所消耗的時間復(fù)雜度就會大大減小
所以如果我切換成大量并發(fā)的話應(yīng)該能看出效果,但是因為ab壓測不成功(設(shè)置并發(fā)數(shù)5000,select模式下壓測報錯),所以反而看不出具體結(jié)果