現在表示中:

対象範囲

以下の図は、パフォーマンスの問題をトラブルシューティングするために実行する必要がある手順のガイダンスを示しています。読みやすくするために、これは 5 つのセクションに分けられています。

図の各手順は、ドキュメントリソースまたは推奨事項にリンクされています。

前提条件と想定事項

パフォーマンスの問題は特定のページ(AEM コンソールまたは Web ページ)で発生し、かつ一貫して再現可能であることを想定しています。パフォーマンスをテストまたは監視するための手段があることが、調査を始めるための前提条件となります。

分析は手順 0 から開始されます。目的は、パフォーマンスの問題の原因であるエンティティ(Dispatcher、外部ホストまたは AEM)を特定し、調査する必要がある領域(サーバーまたはネットワーク)を判別することです。

セクション 1

chlimage_1

セクション 2

chlimage_1

セクション 3

chlimage_1

セクション 4

chlimage_1

セクション 5

chlimage_1

参照リンク

手順 タイトル リソース
手順 0 要求フローを分析します

ブラウザーで標準 HTTP 要求分析を使用して、要求フローを分析できます。Chrome でこの手順を実行する方法の詳細は、以下を参照してください。

https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource-loading
https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing

手順 2 要求の送信元は外部ホストですか ブラウザーで標準 HTTP 要求分析を使用して、要求フローを分析できます。Chrome でこの手順を実行する方法は、上記のリンクを参照してください。
手順 3 要求をキャッシュに保存できますか キャッシュ可能な要求の詳細および一般的な Dispatcher のパフォーマンス最適化に関するアドバイスは、Dispatcher のパフォーマンス最適化を参照してください。
手順 4 要求の送信元は Dispatcher ですか

Dispatcher のデバッグドキュメントを参照して、要求が正しくキャッシュされているか確認してください。

手順 5 Dispatcher は AEM を使用して各要求を認証しようとしていますか Dispatcher が、キャッシュされたリソースを配信する前に、認証のために HEAD 要求を AEM に送信しているかどうか確認します。これをおこなうには、AEM の access.logHEAD 要求を確認します。詳しくは、ログを参照してください。
手順 6 Dispatcher の地理的なロケーションがユーザーから遠く離れていますか Dispatcher をユーザーの近くに移動します。
手順 7 Dispatcher のネットワークレイヤーに問題はありませんか
ネットワークレイヤーで、飽和および遅延の問題がないかどうかを調べます。

 

手順 8 ローカルインスタンスで速度の低下を再現できますか

Tough Day を使用して、実稼動インスタンスから「実際の」状況を再現します。使用する開発環境でこのことが現実的でない場合は、別のネットワークコンテキストで実稼動インスタンス(または同一のステージングインスタンス)をテストしてください。

手順 9 サーバーの地理的なロケーションがユーザーから遠く離れていますか サーバーをユーザーに近い場所に移動します。
手順 10 および 29 ネットワークレイヤーを調査します

ネットワークレイヤーで、飽和および遅延の問題がないかどうかを調べます。

オーサー層の場合は、遅延が 100 ミリ秒を超えないことが推奨されます。

パフォーマンスの最適化に関するヒントについて詳しくは、このページを参照してください。

手順 11 サーバーを近い場所に移動するか、地域ごとに 1 つ追加します  
手順 12 AEM サーバーをトラブルシューティングします 詳しくは、以下の図のサブ手順を参照してください。
手順 13 ハードウェア要件を確認します ハードウェアのサイズ決定のガイドラインに関するドキュメントを参照してください。
手順 14 パフォーマンスの問題のよくある原因を確認します  
手順 15 処理に時間のかかる要求を見つけます

request.log を分析するか、rlog.jar を使用して、処理に時間のかかる要求を確認できます。

rlog.jar の使用方法について詳しくは、このページを参照してください。

rlog.jar を使用した所要時間の長い要求の検索を参照してください。

 

手順 16 サーバーをプロファイリングします

AEM で使用できるプロファイリングツールについて詳しくは、パフォーマンスの監視および分析のツールを参照してください。

手順 17 プロファイリングで処理に時間のかかるメソッドを見つけます  
手順 18 プロファイリングの一般的なシナリオ パフォーマンスの最適化の節で、具体的なシナリオの分析を参照してください。
手順 19 CPU 100 % https://helpx.adobe.com/jp/experience-manager/6-3/sites/deploying/using/monitoring-and-maintaining.html#MonitoringPerformance
手順 20 メモリ不足
  1. メモリ不足
  2. アプリケーションからメモリ不足エラーがスローされる
  3. Helpx で「メモリの問題の分析」を参照してください。
手順 21 ディスク I/O

監視およびメンテナンスのドキュメントで、ディスク I/O の節を参照してください。

手順 22 および 22.1 キャッシュ率 Dispatcher のキャッシュ率の計算を参照してください。

手順 23 処理に時間のかかるクエリ クエリとインデックスに関するベストプラクティス
手順 24 リポジトリチューニング
手順 25 実行されているワークフロー

 

手順 26 MSM インフラストラクチャ

Multi Site Manager のベストプラクティス

手順 27 アセットのチューニング
  1. アセット同期サービス
  2. 複数の DAM インスタンス
  3. こちらおよびこちらにあるパフォーマンスチューニングのヒントに関する記事
手順 28 閉じられていないセッション

 

閉じられていない JCR セッションの確認

 

手順 30 Dispatcher を近くに移動します(または地域ごとに 1 つ追加します)  
手順 31 Dispatcher の前で CDN を使用します CDN での Dispatcher の使用
手順 32 Dispatcher レベルでセッション管理を使用して AEM サーバーをオフロードします

セキュアセッションの有効化

手順 33 要求をキャッシュ可能にします
  1. 一般的な Dispatcher 設定
  2. Dispatcher キャッシュの設定

キャッシュ率を向上させるには、要求をキャッシュ可能にします(Dispatcher のベストプラクティス)。

また、キャッシュ設定を最適化するために、以下の設定も考慮してください。

  1. GET 以外の HTTP 要求にキャッシュなしルールを設定する
  2. クエリ文字列をキャッシュ不可に設定する
  3. 拡張子がない URL をキャッシュしない
  4. 認証ヘッダーをキャッシュする(Dispatcher バージョン 4.1.10 以降で可能)
手順 34 Dispatcher のバージョンをアップグレードします 最新バージョンの Dispatcher は、次の場所でダウンロードできます。
https://www.adobeaemcloud.com/content/companies/public/adobe/dispatcher/dispatcher.html
手順 35 Dispatcher を設定します Dispatcher の設定
手順 36 キャッシュの無効化を確認します
手順 37 および 38 読み込みに時間がかかる AEM Web パフォーマンスに関する Gem セッションを参照してください。
手順 39 事前接続を使用して接続オーバーヘッドを減らします 上記の Gem セッションを参照してください。また、W3c にも preconnect に関する記載があります。 https://www.w3.org/TR/resource-hints/#dfn-preconnect
手順 40 および 41
外部ホストの遅延および応答時間 外部ホストの遅延および応答時間を調べます。
手順 45
および 47

HTTP/2 の使用 手順 37、38 および 39 の Gem セッションを参照してください。また、HTTP/2 サポートに関するこちらのフォーラムへの投稿も参照してください。
 
手順 49 ペイロードのサイズを縮小します Gzip を有効化して、画像サイズを縮小します
手順 42 および 43 Keep-Alive

接続を再利用するために、異なる複数の要求に Keep-Alive ヘッダーが存在しますか。存在しない場合は、要求ごとに別の接続が確立され、不要なオーバーヘッドが発生します。(ブラウザーでの標準 HTTP 要求分析)

プロキシサーバーツールで、Keep-Alive 接続を確認できます。

手順 44 要求はいくつ作成されましたか ブラウザーで標準 HTTP 要求分析を実行します。
手順 46 要求の数を減らします
  1. リソースの連結(画像、CSS スプライト、JSON など)
  2. clientlibs の埋め込み
    1. https://helpx.adobe.com/experience-manager/6-2/sites/developing/using/clientlibs.html#CreatingClientLibraryFolders - 「埋め込みを使用した要求数の最小化」を参照してください。
手順 48 ペイロードのサイズはどのくらいですか ブラウザーの標準 HTTP 要求分析
手順 50 および 51 JS コードがブロックされています https://docs.adobe.com/ddc/ja/gems/aem-web-performance.html

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー