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