パフォーマンス問題の分析と解決

このセクションでは、実装後にパフォーマンスの問題を解決するためのツールと手順について説明します。また、ある環境から別の環境に移行する際のベスト・プラクティスも含まれています。

構成に関連するパフォーマンスの問題を特定する場合、次のステップでは、問題を分離して解決する方法に関するガイダンスを示します。

ユーザー・フィードバックの評価

- 問題が発生したとき、構成のすべての側面に関連するアクションは何でしたか? アクションは、特定のオブジェクト、ビューおよびGroovyスクリプトを指します。
- 問題についてできるだけ具体的な詳細を収集します。正確なナビゲーション・パス、操作の正確な順序、選択された項目、クリックされたボタン、選択されたメニュー、時間、影響を受ける行数。

問題の再現

アプリケーションのロギングを有効にし、自分で問題を再現してください - 詳細は、「ロギング」を参照してください。
問題を再現できない場合:
- 問題をトリガーする外部の問題の可能性の評価 - たとえば、不正なWi-Fi接続です。
- 一連のテストを試してください。テストごとに、レポートされたステップまたはデータの単一の要素を変更して、問題を再現できるかどうかを確認します。
- 問題を再現できない場合は、インシデントの詳細および詳細を追跡 - 将来のレポートと組み合わせる - 問題を分離できるパターンを見つけるのに役立ちます。
この問題はしばらくしか再現できませんか。ロギングを有効にして1回でも問題を再現すると、貴重なインサイトが得られます。問題の再現中にログ・エントリが記録されている場合は、推奨される次のステップについて「アプリケーション・スクリプト・ログの分析」を参照してください。立ち往生している場合は、バグを一貫して再現できないことは、多くの場合、バグをトリガーする条件に関する十分な詳細がないことに等しいことに注意してください。常にできるだけ詳細を収集します。
問題は再現可能であり、一部の外部条件またはイベント(ネットワーク、サーバー負荷)に起因するものではありません - 推奨される次のステップについては、「アプリケーション・スクリプト・ログの分析」を参照してください。

アプリケーション・スクリプト・ログの分析

次の一連のポイントは、アプリケーション・スクリプト・ログを有効にして、一般的なユースケースで問題の原因を分離するための計画の概要を示しています。

スクリプトが多数含まれている場合は、次の質問に答えることで、経過時間ログの候補者のリストを絞り込むことができます。
- パフォーマンスの問題は、特定のページのページ・ロードに関連しますか。
  - ページ・ロード時に実行されるGroovyスクリプト(式フィールド、条件付き更新可能属性、条件付き必須属性、またはこれらのコンテキストで実行されるオブジェクト/グローバル・スクリプト)を実装しましたか。
  - ユース・ケースに関連する新しいカスタム属性を追加しましたか。これらの属性は、前述のようにスクリプトを実装しますか。
  - フェッチおよび表示にコストがかかる可能性がある新しい長いテキストまたはその他のフィールドを追加しましたか。カスタム属性の使用の最適化に関するベスト・プラクティスは、「カスタム属性」を参照してください。
パフォーマンスの問題は変更の保存に関連しますか。
- 保存操作中に実行されるGroovyスクリプト(オブジェクト検証またはトリガー・スクリプトを含む)を最近実装しました - ただし、これに限定されない - データベースに挿入する前に、データベースへの挿入後、データベースへの挿入後、データベースでの更新前、データベースでの更新後、データベースでの削除前、データベースでの削除後、データベースへの変更ポスト後、データベースでのコミット前、データベースでのコミット後、データベースでのロールバック前、またはこれらのコンテキストで実行されるオブジェクト/グローバル・スクリプトのロールバック後)
- ユース・ケースに参加するオブジェクトに新規カスタム属性を追加しましたか。影響を受けるオブジェクトでもページ・ロードのパフォーマンスが低下している場合は、最初にページ・ロードの問題に関するガイダンスを確認してください。ページ・ロード・パフォーマンスが低下していない場合は、これらの属性に関連付けられているスクリプトを確認します。
- この問題をトリガーしたユースケースには、一般的なユースケースよりもはるかに多くの行が含まれていますか。行数が大きいと、パフォーマンスの低いコードの影響が大きくなります。
パフォーマンスの問題はページ上の他のアクションに関連付けられていますか。診断ステップは、ベースラインと比較してパフォーマンスの低下を招くユースケースでも同様です。
- ユースケースの過程で最近実装されたGroovyスクリプトを識別
- 最近実装されたカスタム属性を関連スクリプトとともに識別します。オブジェクトがページ・ロードの低下またはパフォーマンスの保存にも苦しむ場合は、最初にそれらの問題のガイダンスを確認してください。ページのロードおよび保存のパフォーマンスが低下しない場合は、これらの属性に関連付けられているスクリプトを確認します。
- アクションの影響を受けるデータベース行の数を考慮します。

ロギング

アプリケーション・スクリプト・ログ(アプリケーション・コンポーザの共通設定でランタイム・メッセージを選択)は、パフォーマンス関連の問題を含む様々な問題を診断するための重要なツールです。アプリケーション・コンポーザは、ロギングの範囲に特定の制限を設定して、ロギングがアプリケーション全体のパフォーマンスに与える影響を最小限に抑えます。

アプリケーション - ロギングは、アプリケーション・レベルで有効化および無効化されます。特定のロギング・ユース・ケースが複数のアプリケーションにまたがる場合は、アプリケーションごとにロギングを有効にする必要があります。
ユーザー - ログイン・ユーザーは、ユーザーIDのみのロギングを有効または無効にします。ユーザーは、ロギングを有効にするにはアプリケーション・コンポーザにアクセスできる必要があります。
ロギングの有効化と無効化の影響は、printlnコマンドに限定されます:
- ロギングが無効になっている場合、printlnコマンドは何もしません。
- ロギングが有効な場合、printlnコマンドは出力をアプリケーション・スクリプト・ログに送信します。

ロギングをサポートするその他のコード(ログ・コンテンツの生成に使用されるコードなど)は、常にすべてのユーザーに対して実行されます。デフォルトでは、ロギングの有効化または無効化は、println以外のコードには影響しません。これは、主に次のような場合に発生します:

ロギング・サポート・コードは、ロギングをサポートするためにのみ実行される比較的負荷の高い操作を実行しています。
ロギング・サポート・コードは、頻繁に実行されるスクリプトに実装されます - たとえば、属性式スクリプトです。実行の頻度は、そうでなければ無害なコードがパフォーマンスの問題のレベルまで上昇する可能性があります。

println文以外のロギング関連コードの潜在的な影響を制限するには、ロギング・サポート・コードの実装のガイドラインおよびロギング関数の例を参照してください。

アプリケーション・スクリプト・ログを表示するには、アプリケーション・コンポーザの「共通設定」ノードで「ランタイム・メッセージ」をクリックします。次のスクリーンショットでは、SalesアプリケーションおよびJohn Doveユーザーに対してロギングが有効になっています。

ERPおよびSCMクラウドでのランタイム・メッセージ

このイメージは、アプリケーション・コンポーザの共通設定ノードの実行時メッセージを示しています

ロギングは、個々のアプリケーションごとに有効化および無効化されます。この例では、ユーザーはSalesアプリケーションを選択しています。次に、「共通設定」で「ランタイム・メッセージ」を選択します。最後に、ユーザーは「アプリケーション・スクリプト・ロギングの有効化」を確認します。ロギングは、現在のログイン・ユーザーに対してのみ有効であることに注意してください - この場合、John.Doveユーザー。

ロギング・サポート・コードの実装のガイドライン

このコンテキストでは、ロギング・サポート・コードは、ロギングにのみ使用される任意のコード(単純なprintln文以外)を参照します。アプリケーション・スクリプト・ロギングを無効にすると、println文からの出力が無効になります。ロギングにのみ使用されるその他のコードは、すべてのユーザーに対して常に実行されます。

時間やリソースの面でコストがかかるロギング・サポート・コードの実装は避けてください。
パフォーマンスに影響を及ぼす可能性のあるロギング・コード(ログ出力の生成にのみ使用される行のフェッチなど)や、頻繁に実行されるスクリプト(属性式スクリプトなど)へのログインを実装する場合は、使用していないときにそのようなコードが無効になっていることを確認してください。
個々のスクリプトで一般的なロギング・コードを直接レプリケートしないでください。可能な場合は、個々の関数から呼び出すグローバル・ロギング関数で、一般的なロギング関連の作業に集中します。これにより、ロギング・サポート・コードを1箇所で有効化および無効化できます。