検査用のコード スニペットを投稿していないため、そのような「ポーリング」関数を作成するときによく発生するエラーに基づいて回答します。また、jQuery や MooTools などのフレームワークを使用せずに、手動で作業していると想定しています。
この問題は、setInterval の外でそのようなインスタンスを 1 つ作成し、何度も開いて使用するのではなく、各ポーリング呼び出しで新しい XMLHttpRequest オブジェクトを作成することによって引き起こされる可能性が最も高いです。
基本的に、次のようにコードを記述できます。
var pollInterval = setInterval(function() {
var xhr = new XMLHttpRequest(); //ouch, this hurts!
xhr.open('GET', 'url', true);
xhr.send();
//etc.
}, 2000);
このような場合は、XMLHttpRequestObject の作成をポーリング ループの外に移動して、同じオブジェクトを何度も使用するようにします。これにより、ある種のメモリ リークを防ぐことができます (そう呼ぶ場合もあります)。
var xhr = new XMLHttpRequest(); //now we can re-use this!
var pollInterval = setInterval(function() {
xhr.open('GET', 'url', true);
xhr.send();
//etc.
}, 2000);
繰り返しになりますが、コード スニペットや、使用している可能性のあるフレームワークの詳細を投稿していません。したがって、私が提案しているのは、ポーリング ajax コードを調べているときに頻繁に遭遇したエラーに基づいています。お役に立てれば。そうでない場合は、質問を編集してコードを投稿してください。
免責事項: 簡潔にするために XMLHttpRequest オブジェクトのみを使用しました。ベンダーへの憎しみ (または愛) ではありません。明らかに、クロスブラウザーのリクエスト オブジェクト インスタンス化関数を使用するか、これらの厄介な詳細を抽象化するライブラリを使用することをお勧めします。
アップデート
では、コードは 2 秒ごとに dom を更新する必要がありますか? ページがロードされている限り?止まらずに?どこかに clearInterval が表示されると思っていましたが、とにかく。
これは少し厄介です。このような状況に最も近いのは、リアルタイム (OK、1 秒で疑似リアルタイム) グラフを表示するために、ティッカー API に基づいてパルス ラインをコーディングする必要があったときです。私の場合の良い点は、API が非常に高速で、待ち時間が非常に短く、受け取ったデータが単なる float であり、それを使用して行った dom 操作の時空間の複雑さが無視できることでした。
ここでの私の懸念は、サーバーが 2 秒以内に応答しない場合、または応答が 2 秒近くになる場合、複雑なコードの一部がすでにこれらの 2 秒間隔のかなりのミリ秒を消費していることです。DOMは2 秒ごとに更新されない場合があります。
- 衛生上のヒント: の引用符は削除して
window.setInterval("refresh()", 2000)
ください。window.setInterval(refresh, 2000)
理由はここにあります: javascript
setInterval のメモリリーク
- したがって、コードに従って、$.post は確実に 2 秒ごとに新しい XHR オブジェクトを作成します。現実的に、サーバーの応答時間はどのくらいですか? setInterval は何回ループしますか? 低いカウントの場合、たとえば応答時間が 10 秒未満の場合、新しい XHR は「THE」の問題にはなりません。
- 500 行の XML 解析? 間隔ごと?私には苦痛に聞こえます。サーバー上で XML を JSON 文字列にトークン化し、この文字列を UI に返すことはできますか? これにより、クライアントの CPU サイクルが確実に節約されます。
11000 行の HTML。つまり、多くの dom トラバーサルと操作です。ここに小さなチェックリストがあります:
- 最適なセレクターを使用していますか? (xpath 式の特異性)。シズルはあなたをカバーしてくれますが、できる限りのことをしてください. $('p *') のようなものは大混乱を招く可能性があります。
- ドキュメントのリフローを最小限に抑えていますか?
- ループ: 配列に対して for またはマップされた関数を使用するのが最適です (最も効率的です)。
- プロパティ アクセス: ネストされたプロパティ アクセスの繰り返しを減らし、効率化のために 1 回限りの参照を使用していますか?
- 追加/操作効率: たとえば、個々のリスト項目を追加しますか? 理想的には、リスト チャンク全体を一度に追加する必要があります。削除なども同様です。基本的には、繰り返し操作ではなく、分厚い 1 回限りの操作です。
ユースケースの低レベルの意図とメカニズムを理解せずに、これを釘付けにするのは困難です。