SignalR傳輸效能評測-單向傳輸

上篇文章剖析了SignalR的四種傳輸方式: Forever Frame、Long Polling、Server Sent Event及WebSocket,延伸出另一個議題,這四種傳輸方式效率如何? 理論上WebSocket Overhead最少且支援雙向傳送,很有HTML5傳輸霸主之相,但我期待眼見為憑。

我設計了以下的實驗,先測Server端傳至Client端的效率,沿用前文的MarathronHub,以亂數模擬1000筆Runner資料,經由BatchTest()方法一骨腦把1000筆資料拋至Client端: (註: 程式碼改寫自傳輸剖析一文,這裡只提增修的部分,請對照參考)

        public void BatchTest()
        {
            var caller = Clients.Caller;
            foreach (var runner in dataStore.Values)
            {
                caller.addRunner(runner);
            }
        }

聲明在先,實務上我們很少會產生如此兇猛的資料傳輸量,理由有二: 1) 送至前端的資料多半會反應在UI上,短時間產生巨量資料,遠超過使用者視覺所能接收消化的上限,意義不大。 2) 若使用者從Internet連上網站,網路頻寬有其限制,若是透過行動裝置瀏覽,更要考量CPU/Memory負載,能達成巨量資料傳輸的可行性存疑。進一步,設計實務上更建議對即時傳輸加上節流控制,限定單位時間可傳送資料量上限,以維持良好的效能及效果。雖然高速傳送大量資料的情境很少真實上演,這類測試結果還是可視為"壓力測試",具有一定參考價值。

前端程式如下。由?trans=…參數指定傳輸方式,按下測試鈕會觸發Server端BatchTest(),傳回1000筆Runner資料。addRunner()除將資料放入陣列,還一併顯示耗時,遇到最後一筆(runner.Name == "Last"),便將結果產生一筆<li>加至網頁下方列表,方便連續測試記錄之用。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
    <script src="../Scripts/jquery-1.10.2.js"></script>
    <script src="../Scripts/jquery.signalR-2.0.0.js"></script>
    <script src="../signalr/hubs"></script>
    <script>
        $(function () {
            var marathron = $.connection.marathron;
            runners = [];
            var $counter = $("#spnCount"), startTime;
            marathron.client.addRunner = function (runner) {
                runners.push(runner);
                $counter.text(runners.length + "@" + (new Date() - startTime) + "ms");
                if (runner.Name == "Last")
                    $("#ulDisplay").append("<li>" + $counter.text() + "</li>");
            };
 
            var re = /[?]trans=(.+)/;
            var m = re.exec(location.href);
            var transType = m && m.length > 1 ? m[1] : null;
            $("#spnTransType").text(transType);
            // Start the connection
            $.connection.hub.start(transType ? { transport: transType } : undefined)
            .done(function () {
                $(":button").click(function () {
                    startTime = new Date();
                    runners = [];
                    marathron.server.batchTest();
                });
            });
        });
    </script>
    <style>
        fieldset { margin: 6px; }
    </style>
</head>
<body>
    <h3>Transport Type [ <span id="spnTransType"></span> ]</h3>
    <div>
        <input type="button" value="Test" />
        Runner Count = <span id="spnCount"></span>
    </div>
    <fieldset>
        <ul id="ulDisplay"></ul>
    </fieldset>
</body>
</html>

網頁執行效果如下圖:

實測結果如下: (資料定量,時間愈短愈快)

  • IE10 Forever Frame
    545ms, 490ms, 450ms, 517ms, 533ms
  • IE10 Long Polling
    664ms, 693ms, 628ms, 659ms, 618ms
  • IE10 WebSocket
    533ms, 469ms, 564ms, 565ms, 546ms
  • Chrome Long Polling
    343ms, 312ms, 249ms, 280ms, 312ms
  • Chorme Sever Sent Events
    234ms, 249ms, 250ms, 250ms, 218ms
  • Chrome WebSocket
    234ms, 234ms, 218ms, 234ms, 234ms

【結論】

以Server對Client的單向傳輸來說,不管是IE或Chrome,Long Polling都是最慢的,因為每次得到結果後需結束原有Request重發一個新的。排除了Long Polling,IE10的Forever Frame與WebSocket,Chrome的Server Sent Event與WebSocket速度差不多,看不出明顯差距。而你知道我知道獨眼龍都知道的事實是–Chrome比IE10快。

在單純Server傳送給Client的情境,WebSocket並未展現明顯優勢,下回我們再測試雙向傳輸,見識WebSocket的威力。

歡迎推文分享:
Published 04 December 2013 06:59 AM 由 Jeffrey
Filed under:
Views: 9,834



意見

# mis2000lab said on 03 December, 2013 08:29 PM

驚!...Chrome比IE10快....

(捶胸頓足大哭)不可能啊!神功護體啊

神功護體啊

神功護體啊

P.S. 黃飛鴻-男兒當自強的電影台詞  :-)

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<December 2013>
SunMonTueWedThuFriSat
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication