0

Wicket アプリケーションで AbstractAjaxWicketBehavior を使用していますが、AJAX 呼び出しが増えると、時間の経過とともにパフォーマンスが低下するようです。ページが AJAX なしで更新されると、パフォーマンスは再び良好になります。これが通常のことなのか、それとも何らかのメモリリークが存在する可能性があるのか​​ を知りたいですか? コードはより多くのクラスに分散されており、理解するのに多大な労力が必要になるため、単純にコードを添付することはできませんが、要するにこれを行いたいです:

  1. タイマーを作成して開始する
  2. いくつかのコードを10回繰り返す
  3. タイマーを止める
  4. いくつかの値を属性に設定する
  5. ajax の更新 (一部のコンポーネントの表示/非表示が発生します)

同じことをもう一度行います (仮定的に無限回)。

100msの一定の更新間隔を使用しても、このフローの繰り返しはすべて遅くなります。

タイマーは動作であり、再起動または再利用できないため、毎回新しいインスタンスとして作成され、フォーム コンポーネントにアタッチされます。

タイマーは次のようになります。

static int count = 0
new AbstractAjaxTimerBehavior(Duration.milliseconds(100)) {
 // do some code
 count++
 if(count == 10) {
  stop();
  // do some code
 } 
}

この動作は、パネル内のフォームに関連付けられており、AjaxLink をクリックすると、フォームが更新されます (AjaxRequestTarget に追加されます)。新しい動作を追加する前に、フォーム コンポーネントから古いタイマーを削除するたびに。

すべて正常に動作しますが、この手順を繰り返すたびに実行速度が遅くなります (最初の手順は完璧で、2 番目の手順も約 100 ミリ秒ですが、その後遅くなります (10 回または 15 回の繰り返しの後、更新間隔は約 1 秒です))。アプリでの AJAX 呼び出しも大幅に遅くなります)、メモリ リークがあると思われます...明白な理由はありますか? または、改札タイマーを私の目的により良くする方法はありますか? アドバイスをいただければ幸いです。ありがとう。

4

1 に答える 1

2

また、ウィケット アプリケーションは、AJAX リクエストごとに遅くなる傾向があります。これがまったく同じ問題なのか、特に AjaxTimerBehavior に関連するものなのかはわかりませんが、

この原因の 1 つは、HTML の置換によって発生するブラウザーでの疑似リークであることがわかりました。明らかに、nrowser はページがリロードされるまでメモリを解放できません。

タスク マネージャー (または別のツール) を使用してブラウザー メモリを監視し、すべての AJAX 要求でメモリが増加し、ページ全体のリロード (F5) でメモリがどのように解放されるかを監視できます。特にIEで。

ただし、多くの HTML を AJAX リクエストに置き換えます。

于 2012-06-28T08:29:43.697 に答える