workman進程處理問題
環(huán)境workman協(xié)議http://127.0.0.1:8081，Nginx代理跳轉(zhuǎn)到8081，tp5+workman，開8進程，業(yè)務對外curl請求銀行項目，超時3秒；同一時間并發(fā)300+請求，都未超時，想請教一下此時wookman的8進程是否只能并發(fā)處理8個請求，后面的是否都需要排隊？4核4線程CPU怎么發(fā)揮？和Nginx+php+fastcgi比起來處理速度怎么樣，fastcgi可以動態(tài)生成work是不是會好一點？
3個回答
打賞
如果workerman里業(yè)務用curl，8個進程只能并發(fā)處理8個請求，也就是一個進程處理完一個請求后，才會處理下一個，后面的請求排隊。
如果curl改成workerman/http-client，8個進程可以并發(fā)處理更多的請求，每個請求不用排隊，workerman會并發(fā)處理。
如果業(yè)務是調(diào)用curl的話，性能瓶頸在curl，理論上 nginx+workerman比Nginx+php+fastcgi 稍好一些，但是效果差別不大。如果workerman使用workerman/http-client則并發(fā)要比Nginx+php+fastcgi 好很多。
-
-
walkor 2020-07-10
mysql的話直接用同步阻塞就可以了，因為mysql連接數(shù)是瓶頸，mysql默認連接數(shù)一般是100，雖然可以調(diào)高，但是調(diào)高后mysql連接數(shù)過大直接影響mysql性能。一個請求假設發(fā)起3個異步mysql請求，就占用了3個mysql連接，300并發(fā)請求可能直接占用900mysql連接，即使你用了mysql連接池，假設連接池上限100個mysql連接(已經(jīng)很多了)，300并發(fā)打過來還是要排隊，所以mysql異步解決不了多大問題。使用異步+mysql連接池和多開一些進程+mysql單例+阻塞訪問mysql效果其實差不多，但是明顯mysql單例阻塞式訪問代碼更簡單，更穩(wěn)定。
-
-
項目同時用到了，http和websocket，笨拙的寫了個共用處理邏輯的框架。
有一點不清楚，就是websocket協(xié)議下processes設為1時onmessage中收到用戶并發(fā)請求也是同理（同時只能處理一個請求）？
