パフォーマンスツリー performance-tree

CAUTION
AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

範囲 scope

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

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

前提条件と前提条件 prerequisites-and-assumptions

パフォーマンスの問題が特定のページ (AEMコンソールまたは Web ページ ) で発生し、一貫して再現できると仮定しています。 パフォーマンスをテストまたは監視する方法を持つことは、調査を開始する前に前提条件です。

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

セクション 1 section

chlimage_1-103

セクション 2 section-1

chlimage_1-104

セクション 3 section-2

chlimage_1-105

セクション 4 section-3

chlimage_1-106

セクション 5 section-4

chlimage_1-107

手順
タイトル
リソース
手順 0
リクエストフローの分析

ブラウザーで標準的な HTTP リクエスト分析を使用して、リクエストフローを分析できます。 Chrome でこれをおこなう方法について詳しくは、次を参照してください。

https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource-loadinghttps://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 の HEADaccess.log 要求を確認します。詳しくは、ログを参照してください。
手順 6
Dispatcher の地理的な位置はユーザーから遠いですか?
Dispatcher をユーザーの近くに移動します。
手順 7
Dispatcher のネットワークレイヤーに問題はありませんか。
ネットワークレイヤーで、輻輳や遅延の問題がないかどうかを調べます。
手順 8
ローカルインスタンスでは、遅さは再現可能ですか?
用途 Tough Day 本番インスタンスから「実世界」の条件をレプリケートする場合。 開発の場所でこれが現実的でない場合は、異なるネットワークコンテキストで実稼動インスタンス(または同一のステージングインスタンス)をテストしてください。
手順 9
サーバーの地理的な位置はユーザーから遠いですか?
サーバーをユーザーに近づけます。
手順 10 および 29
ネットワーク層の調査

ネットワークレイヤーで、輻輳や遅延の問題がないかどうかを調べます。

オーサー層では、待ち時間が 100 ミリ秒を超えないことをお勧めします。

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

手順 11
サーバーを近い場所に移動するか、地域ごとに 1 つ追加します
手順 12
AEM server のトラブルシューティング
詳しくは、図の次のサブ手順を参照してください。
手順 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/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 は、次の場所でダウンロードできます。

リンク先

手順 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 リクエスト分析)

次の項目を確認できます。 プロキシサーバーツール :キープアライブ接続を確認します。

手順 44
リクエストは何件おこなわれますか?
ブラウザーで標準的な HTTP リクエスト分析を実行します。
手順 46
リクエスト数の削減
  1. リソース(画像、CSS スプライト、JSON など)を
  2. clientlibs の埋め込み:
    1. クライアントライブラリフォルダーの作成 -「埋め込みを使用したリクエストの最小化」の見出しを参照してください
手順 48
ペイロードのサイズはどれくらいですか?
ブラウザーでの標準 HTTP リクエスト分析
手順 50 および 51
JS コードのブロック
AEM web パフォーマンス
recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56