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