大多數(shù)三方lib的底層IO都是采用阻塞式運行的, 這樣一來性能不是又被拉下去了嗎 ?
一個阻塞直接把當前進程的事件循環(huán)都阻塞了, 同一進程下的連接必然要受到連累, 即使開多進程也不能從根源上解決這個問題, 阻塞還是會存在
既然直接用阻塞的第三方組件那么為什么不直接使用 fpm+op 呢 ? 省心省力還高效
好奇, 作者會用 webman 去寫企業(yè)級應(yīng)用嗎 ?
基于fpm的框架性能比webman差很多吧,看下 https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zik073-sf 壓測對比。slim應(yīng)該算是fpm框架里比較快的輕量框架了,同樣的數(shù)據(jù)庫查詢業(yè)務(wù),webman比slim快十多倍。我想應(yīng)該是webman常駐內(nèi)存,數(shù)據(jù)庫連接什么的可以一直復(fù)用,性能才如此出色。
我的理解是如果你的業(yè)務(wù)不需要特別高的性能,那么基于fpm的框架就足夠了。
如果業(yè)務(wù)請求量很大,需要高性能,可以把fpm的業(yè)務(wù)遷移到webman下,
切換成本也很低,因為基于webman和基于fpm下開發(fā)體驗基本沒差別。
至于你說的阻塞,我覺得webman目前是靠多進切換程來解決的,如果阻塞較多,就要多開進程。
不清楚后面會不會采用php8.1自帶的協(xié)程。不過支持協(xié)程后開發(fā)難度肯定是有上升的,
之前基于fpm下寫的代碼和類庫基本上都無法直接用了。
webman群里看到已經(jīng)有很多人用在正式環(huán)境了。
沒有異步IO支持性能應(yīng)該過不了關(guān), 至于為什么壓測會高這個就需要分析了, 就比如多線程讀寫磁盤和單線程讀寫磁盤場景, 由于磁盤只有一個本質(zhì)上還是磁盤在串行讀取, 但不可否認的是, 異步要比同步快, 發(fā)送100個請求出去, 單次請求1s, 如果采用異步可能1~2s 就完成了, 采用同步阻塞則需要100S +, 這樣的場景是不是被拉到和fpm一個級別去了 ? 協(xié)程也只是讓函數(shù)能暫停和恢復(fù), 并不能讓同步阻塞操作變成異步非阻塞, 正是有了協(xié)程的支持, 才能屏蔽掉異步和同步的編程差異
@8086:Webman使用起來基本跟fpm的編碼方式?jīng)]太多區(qū)別,學(xué)習成本較低,但是收益明顯,
swoole這種引入太多自己的東西,成本及收益不成正比,說去zz不正確的話,有這時間我還不如去用go?