.NET WebSocket高并發(fā)通信阻塞問題
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
項(xiàng)目上遇到使用WebSocket超時(shí)問題,具體情況是這樣的,OTA升級(jí)過程中,解壓zip文件會(huì)有解壓進(jìn)度事件,將解壓進(jìn)度通過進(jìn)程通信傳給另一進(jìn)程,通信提示超時(shí)異常 小伙伴堂園發(fā)現(xiàn)大文件使用Zip解壓,解壓進(jìn)度事件間隔竟然是1ms,簡直超大頻率啊 但是,解壓事件超頻也不應(yīng)該通信異常啊,于是我通過1ms定時(shí)發(fā)送通信事件,測試了下進(jìn)程間通信流程。 WebSocketSharp當(dāng)前進(jìn)程間通信組件是基于kaistseo/UnitySocketIO-WebSocketSharp實(shí)現(xiàn),主機(jī)內(nèi)設(shè)置一服務(wù)端,多個(gè)客戶端連接服務(wù)端,客戶端通信由服務(wù)端轉(zhuǎn)發(fā)數(shù)據(jù)??蛻舳薃發(fā)送給B后,客戶端B會(huì)將執(zhí)行結(jié)果反饋給客戶A。 那在定位中發(fā)現(xiàn),各個(gè)鏈路發(fā)送延時(shí)都是正常的,包括服務(wù)端發(fā)送反饋數(shù)據(jù)給到客戶端A,但客戶端A接收數(shù)據(jù)延時(shí)很大,下面是部分返回?cái)?shù)據(jù): 并且通信時(shí)間久了之后,延時(shí)會(huì)越來越大
這里是WebSocketSharp.WebSocket對(duì)外事件OnMessage:
我們繼續(xù)往下看,OnMessage是由WebSocket.message()觸發(fā),從_messageEventQueue隊(duì)列中獲取數(shù)據(jù):
循環(huán)接收數(shù)據(jù)是這樣拿的:
這里我看到了ManualResetEvent。。。數(shù)據(jù)量那么大,這里搞個(gè)同步信號(hào)鎖,肯定會(huì)堵住咯 為何設(shè)置線程同步鎖呢?我們往下看 WebSocketSharp數(shù)據(jù)發(fā)送是基于TCPClient實(shí)現(xiàn)的: _tcpClient = new TcpClient (_proxyUri.DnsSafeHost, _proxyUri.Port); _stream = _tcpClient.GetStream (); 初始化后通過_stream.Write (bytes, 0, bytes.Length);發(fā)送數(shù)據(jù) 接收數(shù)據(jù),也是通過_stream讀取,可以看上方的startReceiving()方法里,WebSocketFrame.ReadFrameAsync (_stream, false,...) 我們知道,TCP是面向連接,提供可靠、順序的數(shù)據(jù)流傳輸。用于一對(duì)一的通信,即一個(gè)TCP連接只能有一個(gè)發(fā)送方和一個(gè)接收方。具體的可以看我之前寫的文章:.NET TCP、UDP、Socket、WebSocket 但接收時(shí)在高并發(fā)場景下,適當(dāng)?shù)耐酱胧┮廊皇潜匦璧摹N覀兛梢允褂胠ock也可以用SemaphoreSlim來實(shí)現(xiàn)復(fù)雜的同步需求,這里使用的是信號(hào)鎖ManualResetEvent 我們?cè)倏纯窗l(fā)送端代碼,也是用了lock一個(gè)object來限制并發(fā)操作:
所以WebSocketSharp在高并發(fā)場景下是存在通信阻塞問題的。當(dāng)然,WebSocketSharp已經(jīng)實(shí)現(xiàn)的很好了,正常的話幾ms都不會(huì)遇到阻塞問題,如下設(shè)置3ms定時(shí)超頻發(fā)送、發(fā)送一段時(shí)間后: 客戶端A發(fā)送消息,由服務(wù)端轉(zhuǎn)發(fā)至客戶B,再將客戶端B的反饋結(jié)果由服務(wù)端轉(zhuǎn)發(fā)回客戶端A,真正延時(shí)才0-2ms!
所以上方項(xiàng)目中遇到的ZIP文件解壓進(jìn)度超快1ms,只能要ZIP解壓處優(yōu)化下,設(shè)置并發(fā)操作10ms內(nèi)保留最后一個(gè)操作,可以參考 .NET異步并發(fā)操作,只保留最后一次操作,即10ms最多觸發(fā)一次解壓進(jìn)度事件。確實(shí)也應(yīng)該這么優(yōu)化,通信即使撐住這種高并發(fā),UI刷新這么高幀率也有點(diǎn)浪費(fèi)CPU/GPU資源。 WebSocket我們?cè)倏纯丛腤ebSocket,寫個(gè)WebSocket通信Demo kybs00/WebSocketDemo (github.com) 服務(wù)端定時(shí)1ms使勁往客戶端發(fā)送Message消息,結(jié)果竟然是: System.InvalidOperationException:“There is already one outstanding 'SendAsync' call for this WebSocket instance. ReceiveAsync and SendAsync can be called simultaneously, but at most one outstanding operation for each of them is allowed at the same time.” 看來發(fā)送事件外部也要處理好高并發(fā)的場景,1ms真的是太猛了
加完信號(hào)量同步,服務(wù)端就能正常發(fā)送了。下面是10分鐘后客戶端接收數(shù)據(jù)打印,傳輸幾乎無延時(shí): 另外,也嘗試了單獨(dú)在客戶端接收添加信號(hào)量同步,依然是提示服務(wù)端發(fā)送不支持并行的異常。 所以原生WebSocket在發(fā)送端加個(gè)需要串行處理比如上面的SemaphoreSlim信號(hào)量,保證完整的寫入完數(shù)據(jù)、執(zhí)行_stream.FlushAsync()。
作者:唐宋元明清2188 出處:http://www.cnblogs.com/kybs0/ 本文版權(quán)歸作者和博客園共有,歡迎轉(zhuǎn)載,但未經(jīng)作者同意必須在文章頁面給出原文連接,否則保留追究法律責(zé)任的權(quán)利。 該文章在 2024/9/5 12:01:31 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |