webman采用阻塞worker模式運行為什么性能還這么高？
問題描述
webman采用阻塞worker模式運行為什么性能還這么高？
為此你搜索到了哪些方案及不適用的原因
既然這樣的話那么假如開啟了100個worker進(jìn)程，那么在瞬時只能實時處理100個請求，每個請求假如500ms，那么第101個請求過來是會被阻塞500ms左右，最后第101次執(zhí)行完成需要耗時500ms + 500ms，這樣的一個機(jī)制難道不會在并發(fā)情況下出現(xiàn)很大的性能問題嗎？
php-fpm、swoole、go，它們都是可以非阻塞的接收請求，不會出現(xiàn)第101個請求打進(jìn)來時受其他請求的影響，所以哪位能給說說這種情況難道真的可以接受嘛？
2個回答
php-fpm 能非阻塞接受請求 ？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
-
-
tanhongbin 2023-07-03
難受，是阻塞的呀，就是你開500進(jìn)程 最多就是接受500個請求，現(xiàn)在webman 有協(xié)程加持 可以處理請求第三方請求阻塞問題了
-
king 2023-07-03
-
fpm開500個進(jìn)程，每個進(jìn)程是獨立的，不會受其他進(jìn)程的影響，而worker的這種模式是復(fù)用worker，所以會造成worker進(jìn)程本身的阻塞，這是兩碼事。
-
“webman 有協(xié)程加持，可以處理請求第三方請求阻塞問題了”，5.0我看過了，目前還沒有發(fā)布正式版本。但真實業(yè)務(wù)中不單單是請求第三方curl，每一個可能存在耗時(IO、cup密集計算等)的操作都會出現(xiàn)以上阻塞情況。
-
-
six 2023-07-03fpm是阻塞處理，雖然可以設(shè)置動態(tài)進(jìn)程數(shù)，但也并不是一個請求創(chuàng)建一個進(jìn)程?，F(xiàn)在基本沒有一個請求創(chuàng)建一個進(jìn)程的服務(wù)器軟件了，因為那樣性能極低。
webman支持fiber協(xié)程調(diào)用第三方接口，第三方接口慢不會阻塞業(yè)務(wù)。
另外看了下源碼，webman也支持swoole/swow作為驅(qū)動，應(yīng)該可以使用swoole或swow的協(xié)程。 -
king 2023-07-03
fpm是同步處理沒有問題，但是我的意思是它的每一次請求都是在一個獨立的進(jìn)程內(nèi)完成的，所以不會因為當(dāng)前的進(jìn)程沒有處理完成而導(dǎo)致其他進(jìn)程出現(xiàn)阻塞請求(前提未達(dá)到設(shè)定的最大進(jìn)程數(shù)量時，因為這又是另外一個概念了)，可能我描述的概念不夠清晰，總之一個復(fù)用進(jìn)程，一個獨占進(jìn)程。
那么就目前而言，webman這個機(jī)制處理一些io操作確實不如swoole這種非阻塞的模式合適。。
-
six 2023-07-03
fpm也一樣，100個進(jìn)程，瞬間第101個請求過來時也是在排隊阻塞等待處理，這和webman沒有多少區(qū)別。
webman本身io處理機(jī)制和swoole是一樣的，都是基于event-loop加非阻塞IO，差別也不大。但是webman身為php層面的框架無法改變PHP內(nèi)置函數(shù)(如PDO)的IO接口阻塞問題，而swoole作為擴(kuò)展可以hook這些阻塞接口變成非阻塞。區(qū)別實際在于這里。說得通俗一點，webman本身的IO是異步非阻塞的，但是業(yè)務(wù)代碼可能是阻塞的。另外webman本身也支持swoole驅(qū)動，可以hook PHP內(nèi)置的IO接口，達(dá)到非阻塞調(diào)用，但是帶來的負(fù)面影響就是和swoole一樣，需要管理上下文。
-
-
-
有棧/無棧協(xié)程本身不具備并發(fā)處理能力，僅僅只是將異步編碼同步化的能力，說白了就是整理代碼執(zhí)行順序的能力，讓你通過簡單的同步書寫的方法就可以輕松實現(xiàn)異步的執(zhí)行；
在主線程上運行的協(xié)程本質(zhì)上和同步阻塞沒有太大區(qū)別：
- 同步阻塞下：100個請求打在一個worker進(jìn)程上，和阻塞隊列類似，隊列容量就是socket buffer的大小，只要buffer足夠多，worker進(jìn)程就可以繼續(xù)接收請求等待；假設(shè)每個請求需要2秒執(zhí)行完成，那么100個請求需要200秒完成。
- 主線程協(xié)程下：100個請求被稀釋在協(xié)程中，每個協(xié)程棧儲存了這個請求的上下文，所有上下文由協(xié)程調(diào)度器來進(jìn)行運行，看起來就如同把socket buffer交給協(xié)程棧來保存了而已。
所以現(xiàn)在的協(xié)程調(diào)度器至少都是另起一個/多個線程來執(zhí)行，保證不阻塞主線程，主線程主要負(fù)責(zé)接收，然后拆分丟給協(xié)程調(diào)度器，看起來就是一個迷你的基于線程的master-worker模型；
再說回MySQL或者Redis等服務(wù)，他們是C/S架構(gòu)的服務(wù)，所以一個進(jìn)程/線程上可以啟動多個client，多個client在宏觀上看起來就是多個線程，因為可以并行執(zhí)行（Redis客戶端也同樣，但執(zhí)行命令時是單線程），這個時候利用多個協(xié)程來向多個client發(fā)起請求的時候，本質(zhì)上是利用了多線程，因為每個client的消息是不會相互阻塞的，本質(zhì)上也是因為這些服務(wù)是支持并行處理的；而workerman這邊只是顆粒度粗一些，是一個進(jìn)程對應(yīng)一個/多個client，但是相互阻塞排隊的；
結(jié)論：看性能的話，主要看最后并行的情況，和縮減阻塞等待的時間，并行就是利用多核，目前來說利用多核就是進(jìn)程/線程，不論是自身利用還是所使用的服務(wù)利用，都是利用。
