8

現在のプロジェクトでは、既存の XPage アプリケーションを高速化するという一般的な要件があります。私たちが検討したことの 1 つは、一部の遅い先行入力フィールドを高速化する方法でした。これに対する高速と思われる解決策の 1 つは、元々あった DBColumn ではなく FTSearch を使用して実装することです。これが適切なアプローチであるかどうか、または必要なことを別の方法で行うための提案があるかどうかについて、アドバイスを求めたい.

背景: 速度に影響を与える要因は多数ありますが (ネットワーク遅延、サーバー OS、使用可能なサーバー メモリなど)、8.5.3 を使用しているため、可能な限り一般的にアプリケーションを最適化しました。問題領域を見つけるための IBM ツールキットの使用、および 8.5.3 でこれを支援するために IBM が追加した機能 (例えば、部分実行、最適化された JS および CSS オプションの使用など) の使用。残念ながら、3.5Gb RAM を搭載した 32 ビット Windows OS で実行されているサーバーで、さらに数か月間立ち往生しています。

応答が最も遅い要素の 1 つは、多数のドキュメントを参照する特定の先行入力です。最悪の場合、先行入力が有効なフィールドの候補リストが表示されるまでに、平均で約 5 ～ 6 秒かかります。SSJS を使用して Java クラスを呼び出し、(Ferry Kranenburg の XPages Snippetを使用して) dbcolumn 呼び出しを実行し、ビューから一意のリストを取得してから、SSJS に戻って配列をループし、各エントリに検索キー値が含まれているかどうかを確認します。見つかった場合は、単語内の検索テキストの周りに強調表示 (太字) の html タグを追加し、書式設定されたリストをブラウザーに返します。コードの実行にかかる経過時間を出力する print ステートメントを追加しました。今日の開発サーバーでの平均時間は約 3250 ミリ秒です。

このプロセスを高速化する方法を確認するために、いくつかのことを試しました。

  1. すべての処理を行う Java クラスを追加しました (SSJS を使用しないため)。これにより、平均 100 ミリ秒しか節約できませんでした。

  2. ビュー スコープのマネージド Bean を使用して、ページの読み込み時に一意のルックアップ リストをメモリに読み込みました。これにより、非常に高速な先行入力応答 (16 ミリ秒) が生成されますが、これは大規模なデータ セットでこれを行うには非常に悪い方法であると思われます。また、複数のユーザーがアプリケーションにアクセスしている場合、一般的なサーバーに実際に影響を与える可能性があります。ラージ オブジェクトと見なされるものに関する情報を見つけようとしましたが、メモリに格納するには大きすぎるというガイダンスや推奨事項を見つけることができませんでした (JSF と XPage のサイトを検索しました)。これに関する提案はありますか？

  3. まだJavaクラスです-dblookupを実行して検索するすべての値の「リスト」を取得する代わりに、コードでFT検索を実行してドキュメントコレクションを取得し、各ドキュメントをループして必要なフィールド値を抽出し、それらを「SortedSet」に追加し（自動的に重複を許可しません）、ソートされたセットをループして検索語の周りに太字のタグを挿入し、それをブラウザに返します。これには平均 100 ミリ秒かかります。これは素晴らしく、ほとんど目立ちません。このアプローチには欠点がありますか、またはこの方法で行うべきではない理由はありますか?

これに関するフィードバックやアドバイスをありがとう。パム。

2013 年 8 月 14 日更新: 別のアプローチ (OpenNtf の IBM/Tony McGuckin Insights アプリケーションに触発された) を試しました。これは、マネージ Bean を使用し、大量のデータで高速な Company Search の先行入力です。

4 . Insights アプリケーションは複数のデータベースに分割されたデータを処理しますが、先行入力の原則は似ています。エントリの先頭だけでなく、テキスト内の文字列も検索する必要があったため、getAllEntriesByKey でビューを使用できませんでした。ビュー FTSearch に基づいて ViewEntryCollection を作成しようとしましたが、列に重複した名前がたくさんあるため、必要な一意のリストが得られませんでした。次に、分類されたビューで NotesViewNavigator を使用して、それをループしてみました。これにより、必要な一意のリストが作成されましたが、上記の他のどの方法よりも遅いことが判明しました。(これらのViewNavigator パフォーマンスのヒントを実装しました)。

4

3 に答える 3

4

私の見解では、(XPages だけでなく) すべての Domino アプリケーションが構成する多くのレイヤーのいずれかによって、パフォーマンスが影響を受ける可能性があります。上から - ブラウザー (DOM、JS、CSS、HTML...)、ネットワーク (レイテンシー、DNS、SSO...)、アプリケーション層 (効果的なアルゴリズム、キャッシュ)、データベース/API (データ量、インデックス、リーダー名) ...) および OS/ハードウェア (ディスク、メモリ...)

あなたがテストしたことによると：

  1. これは興味深いことですが、SSJS はキャッシュされ、下位レベルの API を使用してデータ (NAPI) を取得する可能性があります。
  2. あなたの環境 (32 ビット/3.5G RAM - 3.5M に関するあなたの記述はタイプミスだと思います) では、特に多くのフィールド/フォーム/アプリケーションにパターンとして適用する場合は、大きなリストをキャッシュすることはお勧めしません。ただし、WeakHashMap のキャッシュはより安定している可能性があります。
  3. 頻繁に更新されるデータが必要でない限り、FT 検索の使用はまったく問題ありません。FT インデックスを更新するには、ある程度の時間とリソースが必要です。

私の提案は次のとおりです。問題が解決する場合は、FT を使用してください。間違いなく、最初にサーバーでの重いパフォーマンス テストで FT パフォーマンスのトラブルシューティングを行います。

于 2013-08-12T20:11:56.857 に答える
1

FT 検索の 1 つの問題は、次のエラーです。

このデータベースの全文索引は使用中です

私の経験に基づくと、これは、インデクサー タスクがデータベースのインデックス作成を開始するときにしばらくの間 (おそらく数秒) 発生します。ユーザーの要求がそれほど厳しくない場合は、再試行するだけで、おそらくうまくいくでしょう。

しかし、多くの場合、ユーザーが受け取るエラーを最小限に抑えたいと考えており、このエラーを適切に処理する必要があります。FTSearch少し待って、エラーが受信されなくなるまで再試行する独自のメソッドを作成しました。これは、エラーではなく速度低下としてユーザーに表示されます。

于 2013-08-14T12:39:01.547 に答える