2009-08-14 15 views
5

XHRオブジェクトを破棄せずにXHRオブジェクトのresponseTextを消去する方法はありますか?Comet、responseText、memory usage

ライブデータをブラウザに送るには、Webサーバーに対して永続的な接続を開いたままにしておく必要があります。問題は、相対的に大量のデータが入っていること(数百K /秒)があることです。この接続は少なくとも数分間は開いたままでなければならないため、メモリ使用量は大きな問題です。 responseTextは非常に速く非常に大きくなります。私が返すJSONは、できるだけ小さなものにクランチされています。

AJAX形式の短いポーリングを使用してXHRオブジェクトを破棄するだけで、サーバー側のアプリケーションが動作するため、数ミリ秒でも重要なデータが大量に失われます応答を解析し、新しいXHRを作成して送信します。 Webサーバーは一度に1つの接続しか受け付けないため、重複する要求を使用するオプションはありません。 (尋ねないでください)そう、彗星はまさに私が必要とするモデルです。

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

ここに欠けている画像の部分はありますか?誰かが私がそれを読んでいるときに私がresponseTextを解放するのに使うことができるどんなトリックも知っていますか?または、サーバーの応答が行く別の場所がありますか?

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

答えて

1

これはちょっとしたポーリングの仕組みです。最後に読んだ行番号に索引をつけ、間隔の各ティックをその点以降に読み込みます。 1つの長い接続、したがって1つの長い応答です。

新鮮なresponseTextは、新しい接続を意味します。しかし、それはもはや彗星ではないだろう;)

+0

ありがとうございました。私はそのモデルを理解している。私はちょうどその接続で今まで受信したことのあるものすべてを巨大なバッファに格納することなく、接続を維持する方法があることを期待していました。 ロングポーリングはとにかくハックですので、私はそれが必要な方法で正確に動作したいと思っていますね。 – glomad

+1

@ithcy:実際は妥当な要求のようです。私はあなたが尋ねるまでずっとそれについて考えなかった。 'xhr.flushResponseBuffer()'や何かが長時間実行されている接続にとって貴重なものになることがあり、常時回線番号参照を節約する必要がありません。 –

4

"ロングポーリング"とは対照的に、長いポーリングは1つの長い接続ではありません。 「ロングポーリング」とは、多くの接続が順番に並んでおり、応答が必要ない場合は、それぞれの接続が適度な長時間接続された状態を保ちます。それらはを実行します。はタイムアウトします(通常25-30秒程度)。その後、新しい接続を再確立します。 HTTP1.1は既存の接続の再利用を可能にするため、接続を再ネゴシエートする必要はなく、実質的に即座に再確立することができます。

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

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