40 個の xpages、60 個のカスタム コントロール、および cca を使用した xpages アプリケーションがあります。50 個の Java ファイル (src ... パッケージ エクスプローラーで使用) アプリケーションの読み込みを高速化するために、notes.ini でこれら 2 つの変数を使用しました。
XPagesPreload=1
XPagesPreloadDB=account/w-apps.nsf
(I use the latest 853FP1)
私が見ることができるログでは、これらの変数が使用されていますが、これにもかかわらず、最初のページが表示されるまで常に約 7 秒待たなければなりません (次回は高速です)。そして、たとえば何時間もアプリケーションを使用しないと、アンロードされているように見え、もう一度待たなければなりません。最後に、アプリケーションを 1 時間に 1 回使用すると、常にしばらく待たなければならず、面倒です。これらを高速化/克服する方法、または少なくともアプリケーションのアンロードを回避する方法はありますか?
セッション時間を控えめに保つこともできますが、匿名でアクセスできる 1 つのページで @URLOpen を実行するだけのスケジュール エージェントを使用します。これにより、アプリケーションがタイムアウトするのを防ぎます。これを行うには、匿名を「アクセスなし」に設定しますが、「公開ドキュメントを読む」をチェックしてから、1 ページを「パブリック アクセス ユーザーが利用可能」としてチェックします。ページは何もせず、「OK - 了解しました」を返すだけです --- ただし、アプリケーション コンテキストは維持されます。
エージェントを 08:00 から 18:00 に実行するようにスケジュールすると、アプリは通常の勤務時間中に稼働します
これは、xPages でよくある問題です。一定の時間が経過すると、サーバーはアプリケーションをアンロードして、他のアプリケーションのためにメモリを解放します。あなたが探している設定は次のとおりです。
xsp.application.timeout
nsf / サーバーの xsp.properties ファイル内。この数値を変更すると、サーバーのタイムアウトに時間がかかりますが、次のことに注意してください。
また、メモリ不足エラーの原因となるセッションのメモリがクリアされないことも意味します。
アプリケーションの読み込みに 7 秒かかる場合は、バックグラウンドで多くの処理が行われています。まず、アーキテクチャを最適化し、サーバーのメモリ設定を最適化 ( jvm heapsize ) できるかどうかを確認し、サーバーの仕様がボトルネックになっていないかどうかを確認するのが賢明だと思います。
XPagesPreload私の意見では、設定は奇妙でまったく役に立ちません。HTTP タスクまたはサーバーを起動するまれなイベントでのみ、それらをプリロードします。XPage が 2.5 時間アクセスされない場合、アンロードされます。8.5.2 でテストしたときに、この 2.5 時間に気付きました。Domino 9 では、数時間後にアンロードされることを知っています。おそらくまだ 2.5 時間です。
7 秒の読み込み時間よりもはるかに大きな問題がありました。特定の XPage が最初に読み込まれたときは、1 ～ 3 分でした。David Leedy も同様の読み込み時間について言及しています。
いくつかのテストの後、速度低下はビュー パネルが原因で、ドキュメントが全文検索を使用して取得され、並べ替えられることが原因であることがわかりました (並べ替えが関連しているかどうかはわかりません)。これにより、ビュー インデックスが大きい場合、初期ロード時間が非常に長くなります。最初のページの後、さまざまな全文検索で 1 ～ 3 秒でページが読み込まれます。ビュー インデックスは、12 列を双方向に並べ替えることができるため (顧客の要件)、ほぼ 0.7 GB でした。遅さはbeforeRenderResponseとafterRenderResponseイベントの間でした。
顧客がこれら 24 個のソート インデックスをすべて使用するとは思えなかったので、各列の [最初に使用するまでインデックスの作成を延期する] オプションをオンにしました。次に、ビュー インデックスを破棄しましたが、これまでのところ小さいままで、朝の最初の読み込みは数秒になりました。