5

XHR オブジェクトを破棄せずに XHR オブジェクトの responseText をクリアする方法はありますか?

ライブデータをブラウザーにフィードするために、Web サーバーへの永続的な接続を開いたままにしておく必要があります。問題は、比較的大量のデータ (常に 1 秒あたり数百 K) が通過するため、この接続が少なくとも数分間開いたままにしておく必要があるため、メモリ使用量が大きな問題になることです。私が送り返す JSON は可能な限り小さく砕かれていますが、responseText は非常に急速に大きくなります。

サーバー側アプリの動作方法が原因で、AJAX スタイルのショート ポーリングを使用し、処理が完了したときに XHR オブジェクトを破棄すると、解析にかかる数ミリ秒であっても、大量の重要なデータが失われます。応答し、新しい XHR を作成して送信します。Web サーバーは一度に 1 つの接続しか受け付けないため、重複するリクエストを使用するオプションはありません。(聞かないでください。) したがって、Comet はまさに私が必要としているモデルです。

私がやりたいことは、サーバーから返された各 JSON チャンクを解析し、responseText をクリアして、同じ接続を使い続けることができるようにすることです。ただし、responseText は読み取り専用です。私が見つけた方法で直接空にすることはできません。

ここに欠けている写真の一部はありますか？読み終わったときに responseText を解放するために使用できるトリックを知っている人はいますか? または、サーバーの応答を送信できる別の場所はありますか?

これは実際にはほとんどコードにとらわれない質問であるため、コードは含めません。XHR を生成し、返されたデータを処理する Javascript ルーチンは非常に単純です。

4

2 に答える 2

4

他の応答とは対照的に、「ロングポーリング」は 1 つの長い接続ではありません。「ロングポーリング」とは、多数の接続が順番に行われることであり、応答が必要ない場合、それぞれがかなり長い時間接続を維持するように設定されています。それらはタイムアウトし (通常は 25 ～ 30 秒程度)、新しい接続を再確立します。HTTP1.1 では既存の接続を再利用できるため、接続を再ネゴシエートする必要がなく、実質的に瞬時に再確立できます。

したがって、複数のリクエストを使用してください。接続を再確立するためのオーバーヘッドはごくわずかであり、新しい接続ごとに以前の応答テキストを破棄できるため、これはパフォーマンス/オーバーヘッドの観点から完全に実行可能なソリューションであり、メモリの問題も解決します.

[編集] WebSyncの作成者の 1 人として、私は経験から話しています。

于 2010-04-01T03:59:20.797 に答える
1

それが、ロングポーリングの仕組みです。最後に読み取った行番号へのインデックスを保持し、その時点から間隔の各ティックを読み取ります。これは 1 つの長い接続なので、1 つの長い応答です。

フレッシュresponseTextとは、フレッシュなつながりを意味します。しかし、それはもう彗星ではありません;)

于 2009-08-14T04:57:31.450 に答える