BusinessWorker面對高并發(fā)出現(xiàn)busy
最近BusinessWorker 接收消息面對高并發(fā)請求(每秒起碼幾十條數(shù)據(jù),每條數(shù)據(jù)50-100字節(jié))就會出現(xiàn)busy,沒有操作數(shù)據(jù)庫之類的只是做轉(zhuǎn)發(fā)處理,從出現(xiàn)的情況來看和連接數(shù)也多少也沒有直接關(guān)系,查看日志后里面讓我去看: See http://wiki.workerman.net/Error2 for detail 這個網(wǎng)頁,看了后說是業(yè)務(wù)造成死循環(huán)導(dǎo)致的,但是從我代碼來看并不會出現(xiàn)死循環(huán),隨后我在發(fā)送消息時我在業(yè)務(wù)處理前監(jiān)測它,但是并沒有第一時間收到數(shù)據(jù),而我在業(yè)務(wù)處理完后也監(jiān)測它,只要我接收消息就在業(yè)務(wù)處理中就不會產(chǎn)生延遲,說明是在發(fā)送信息中就阻塞的,說得有點長和啰嗦,沒明白的我可以再解釋
1個回答
打賞
可能是客戶端發(fā)送的消息速度快于你業(yè)務(wù)處理的速度。
比如所有客戶端加起來每秒向服務(wù)端發(fā)送100個消息，而服務(wù)端處理一個消息要20毫秒，那么服務(wù)端每秒只能處理50個消息(只有一個businessWorker進程情況下)，那么每秒就會有50個消息沒處理積壓在隊列，隨著時間推移隊列里數(shù)據(jù)一直積壓直到隊列滿，然后就報 sendbuffertoworker fail.may be the send buffer are overflow 錯了。不要想著增加隊列大小解決這個問題，只能稍稍緩解，無法根本解決。
如果businessWorker進程里的業(yè)務(wù)邏輯有死循環(huán)或者長時間阻塞，或者其它耗時的任務(wù)，也會大大降低businessWorker進程進程處理消息的速度，更容易造成sendbuffertoworker fail.may be the send buffer are overflow 錯誤。
你可以計算下服務(wù)端處理每個請求的時間，還有客戶端發(fā)送的速率，看看是否能夠及時的處理每個請求而不一直積壓。
解決這個問題的關(guān)鍵就是處理請求的速度夠快。
-
-
walkor 2018-07-12
這幾個方法中g(shù)etClientCountByGroup是比較耗時的，getClientCountByGroup和sendToGroup，比較耗系統(tǒng)資源。
-
新人 2018-07-12
@1:那么這個問題是不是就是個硬性問題了,只能減少發(fā)送數(shù)據(jù)才能解決,還有個問題,安裝了event擴展后還用不用做什么操作,查看資料還要編寫event的代碼,這就很懵逼了
-
walkor 2018-07-12
嗯，服務(wù)器硬件+框架+業(yè)務(wù)代碼 結(jié)合在一起肯定有個極限，并非多大的請求量服務(wù)端都能承受。event擴展安裝成功了就自動使用了，不用其它編碼。
