之前寫了一篇文章,做了一個粗疏的測試.來證明,在慢資料庫查詢下,swoole跟php-fpm的併發數一樣地少.相差無幾.經過網友的討論和指教.我發現我的結論是錯誤的且有可能誤導其他開發者.
所以現在找一個更加貼近現實的生產環境的測試方法.這裡先說結論,swoole是真正能解決php專案效能差,併發低的方案之一.
這裡首先要說php-fpm的多程式模式,php-fpm的處理方法.只會一個請求一個請求地處理.怎麼證明這個事情?可以寫一個sleep(30)秒的介面.開2個靜態程式.快速請求兩次.然後再去請求其他沒有阻塞的介面.看看是不是連其他正常的介面也請求不了.如果是,就能說明php-fpm的處理方法.
但php-fpm的程式是獨立.嚴格上說一個程式慢,需要時間處理,是不會影響其他程式的響應時間的.你可以這樣試,同樣開兩個php-fpm程式,請求一次sleep(30)秒的介面.然後同時壓測另外正常的介面.QPS還是有可能上千的.但如果慢的介面的請求把所有的php-fpm程式都佔用了,就會影響都其他正常介面的響應速度.出現類似 “阻塞” 的現象.
這個情況也是一般php專案速度慢的情況.我認為在介紹swoole的好處時候.說php-fpm開銷大,每次載入框架程式碼這些其實意義不大.因為一個介面用php-fpm寫響應速度是 100ms.換成swoole框架能提高 到80ms.個人認為意義不是特別大.
壓測方法,
寫兩個介面,一個等待一秒返回,另一個hello world.同時壓測.這樣的目的是模擬生產環境.有個別的介面特別慢.拖慢了整個專案的請求速度.
php-fpm sleep程式碼
sleep(1)hyperf sleep1秒介面
try {
$Client= new Client();
$Client->get("https://www.google.com",["timeout"=>1]);
}catch (\Exception $exception ){
}
hello world程式碼
echo "hello word"單獨壓測hello world介面
wrk -c 100 -t 10 -d 10s tp8.localhost/index/index
QPS 1871
sleep介面和hello world介面,同時壓.
wrk -c 10 -t 10 -d 10s tp8.localhost/sleep/index/
wrk -c 100 -t 10 -d 10s tp8.localhost/index/index
hello world介面 QPS 19.97
hyperf 不用sleep模擬慢介面,用http請求來模擬.
hello world介面單獨壓測
wrk -c 100 -t 10 -d 10s 127.0.0.1:9501/index
QPS 58576
sleep介面和hello world介面,同時壓.
wrk -c 10 -t 10 -d 10s 127.0.0.1:9501/sleep
wrk -c 100 -t 10 -d 10s 127.0.0.1:9501/index
hello world介面 QPS 56826
hello world介面幾乎沒有受慢介面影響
單個介面請求,php-fpm跟swoole也許有10倍的差距.但是這個不是重點.重點是採用swoole框架寫的專案整體不會被慢的介面拖慢.這個比較有意義.
這裡說的swoole效能比php-fpm強10倍.不是說一個介面用來用php-fpm請求時間是1秒,改用了swoole框架就變成了0.1秒.
而是說某些情況.swoole的併發數可以比php-fpm高10倍.
為什麼php-fpm會出現”阻塞”的情況.和什麼情況下才會出現阻塞.
php-fpm程式數是20,一個sleep(1)的介面,每秒併發請求數為20.這樣就會把20個程式用佔用.而其他介面的請求就會出現”阻塞”的情況.因為沒有程式可用了,但如果併發是10去請求慢介面.還有剩下10個程式去處理其他介面的請求.這時候就不會出現”阻塞”.
google請求解釋
$Client->get("https://www.google.com",["timeout"=>1]);解釋一下請求google地址,在牆內一定是請求不到的.設定1秒超時.為了代替php-fpm的sleep1秒.
本作品採用《CC 協議》，轉載必須註明作者和本文連結