timer - signalR のオーバーヘッド

Question

新しい場所を定期的に (4 秒ごとに) 送信して、サーバー上の位置を更新するクライアントがあります。サーバーを定期的に（5秒ごとに）ポーリングし、最新の場所を取得することにより、以前のモバイルを追跡するクライアントもあります。

この通信は、SignalR (最新の場所を送信するため) またはタイマーを使用して実行する必要がありますか? これは、SignalR にはオーバーヘッドがあり、非常にコストがかかる大きな要求サイズを生成するためです。

ライアン、ありがとう

Answer 1

HTTP通信勝利

現在、私があなたの説明を理解していることに基づいて、複数の更新 POST を実行しており、リスナーはポーリング GET 要求を使用しています。これらには、ヘッダー付きの個別の HTTP 要求のオーバーヘッドがあり、キープアライブを使用していない場合、またはキープアライブ タイムアウトを超えている場合は、TCP 接続を [再] 確立します。

SignalR を使用すると、代わりに最低限、ポーリングの GET 側を改善できます。これは、SignalR が単一の HTTP GET 要求を介して複数の応答を送り返す長いポーリングを使用できるため、常にではなく「リアルタイム」で実行できるためです。ハードな 4 秒のラグ タイムがあります。そこから、クライアントとサーバーの機能に応じて、Server Sent Events (SSE) を介して本格的な Web ソケットに到達することができます。これらのアプローチはいずれも、現在説明している実装よりも効率的です。

リクエストサイズの勝利

各 SignalR メッセージを囲む小さな "エンベロープ" だけがあります。HTTP ヘッダーと比較すると、ブラウザー クライアントは更新のたびに POST を送信し、GET をポーリングする必要があります。SignalR はこれを簡単に解決できると思います。明らかに、メッセージのペイロードはどちらの場合も同じ JSON になるため、それは無駄です。

プログラミング モデルの勝利

最も重要なことは、SignalR を使用することで、最終的に使用される基礎となる手法を抽象化し、切断されたリクエストにダウンダウンすることを最終的に心配する必要がなく、一貫したリアルタイム通信 API を提供するプログラミング モデルが得られることです。レスポンスモデル。