1

毎秒クライアントに送信される単一のオブジェクトに含まれる最大 10,000 行のリアルタイム データ ティッカーに SignalR を使用しています。IIS ワーカー プロセッサのメモリは、ティックが最終的にフリーズするまで増加し続けます。

4

1 に答える 1

4

まず第一に、すでにお読みのとおり、SignalR は大きなメッセージを送信しないことを前提に構築されています。ただし、実際には、これは完全に有効なシナリオです。

それで、メモリの問題との取り決めは何ですか。SignalR には、既定のサイズが 1000 要素の循環バッファーがあり、開いている接続ごとにすべてのメッセージをそのバッファーに格納します。したがって、基本的に、100 の開いている接続があり、1000 のメッセージを送信した場合、合計 100*1000 のメッセージがメモリ内に保存されます。

考慮すべきもう 1 つの点は、.Net フレームワークのラージ オブジェクト ヒープとガベージ コレクションです。サイズが 85kB を超えるすべてのオブジェクトは、大きなオブジェクト ヒープに移動します。次に、ガベージ コレクターが大きなオブジェクト ヒープ内のオブジェクトを第 2世代のオブジェクトとして扱うことを指摘する必要があります。これを考慮すると、SignalR の循環バッファーから逆参照されたオブジェクトは、サイズが原因ですぐにガベージ コレクションされないことがわかります。

@davidfowlが言ったように、実際にはデータを小さくすることができますが、クライアントとサーバーの両方にかなり複雑なメカニズムを導入しないとできない場合があります.

幸いなことに、SignalR の循環バッファーの既定のサイズを小さくする方法があり、次のように設定することで実行できます。

GlobalHost.Configuration.DefaultMessageBufferSize = 32
于 2015-09-30T20:35:53.867 に答える