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