パフォーマンスの最適化

主な問題は、Web サイトが訪問者のリクエストに応答するのに要する時間です。 この値はリクエストごとに異なりますが、平均ターゲット値を定義することもできます。 この値が達成可能で維持可能であることが判明したら、Web サイトのパフォーマンスを監視し、潜在的な問題の発生を示すために使用できます。

対象オーディエンスの様々な特性を反映し、オーサー環境とパブリッシュ環境では、対象となる応答時間が異なります。

オーサー環境

この環境は、作成者がコンテンツを入力および更新する際に使用します。 コンテンツページとそれらのページの個々の要素を更新する際に、パフォーマンスを集中的に消費するリクエストの数が多い数のユーザーに対して注意する必要があります。

パブリッシュ環境

この環境には、ユーザーが使用できるようにするコンテンツが含まれています。 ここでは、リクエストの数がさらに多くなり、速度も非常に重要です。 しかし、要求の性質は動的ではないので、追加のパフォーマンス向上メカニズムを適用できます。例えば、コンテンツのキャッシュやロードバランシングをおこなう場合などです。

パフォーマンスの最適化方法

AEM Projects のパフォーマンス最適化手法は、5 つのシンプルなルールにまとめて、最初からパフォーマンスの問題を回避するために従うことができます。

1. 最適化の計画
2. 実際の状況に近いシミュレーション
3. 適切な目標設定
4. 妥当性の維持
5. アジャイルな反復サイクル

これらのルールは、一般に Web プロジェクトに適用され、プロジェクトマネージャーやシステム管理者に関連しており、起動時にプロジェクトのパフォーマンスに関する課題が発生しないようにします。

最適化の計画

パフォーマンス最適化フェーズでは、プロジェクト作業の約 10%を計画します。 実際のパフォーマンス最適化要件は、プロジェクトの複雑さのレベルと開発チームの経験によって異なります。 プロジェクトに割り当てられた時間が（最終的に）必要ない場合がありますが、推奨地域でのパフォーマンス最適化を常に計画することをお勧めします。

可能な限り、プロジェクトは限られたオーディエンスに対してソフトローンチし、実際のエクスペリエンスを収集し、完全な発表に続く追加の圧力なしに、さらに最適化を実行する必要があります。

「ライブ」になった後は、パフォーマンスの最適化は終了しません。 現在は、システムで「実際」の負荷が発生しています。 起動後に追加の調整を計画することが重要です。

システムの負荷が変わり、システムのパフォーマンスプロファイルが時間の経過と共に変化するので、パフォーマンスの「調整」または「ヘルスチェック」は 6 ～ 12 ヶ月間隔でスケジュールする必要があります。

実際の状況に近いシミュレーション

Web サイトを利用して運用を開始し、起動後にパフォーマンスの問題が発生した場合は、負荷テストとパフォーマンステストが十分に実際の動作をシミュレートしていなかった可能性が高くなります。

現実のシミュレーションは難しく、「現実」を得るためにどれだけの労力を費やしたいかは、プロジェクトの性質によって決まります。 「実際」とは、「実際のコード」と「実際のトラフィック」だけでなく、特にコンテンツのサイズと構造に関して、「実際のコンテンツ」を意味します。 テンプレートの動作は、リポジトリのサイズと構造によって異なる場合があります。

適切な目標設定

パフォーマンス目標を適切に設定することの重要性は、過小評価されてはいけません。 多くの場合、特定のパフォーマンス目標に焦点を当てた後は、仮定に基づいている場合でも、後でこれらの目標を変更するのは困難です。

優れた、確実なパフォーマンス目標を確立することは、実際に最も難しい領域の 1 つです。 多くの場合、同等の Web サイト（新しい Web サイトの前に使用した Web サイトなど）から実際のログとベンチマークを収集するのが最適です。

妥当性の維持

ボトルネックは一度に 1 つずつ最適化することが重要です。 1 つの最適化の影響を検証せずに並行して処理を行おうとすると、どの最適化測定が役立ったかを追跡できなくなる場合があります。

アジャイルな反復サイクル

パフォーマンスの調整は、目標に達するまで、測定、分析、最適化、検証を繰り返しおこなうプロセスです。 この点を考慮するには、各反復後に、より重いテストプロセスではなく、最適化フェーズに機敏な検証プロセスを実装します。

つまり、最適化を実装する開発者は、最適化が既に目標に達しているかどうかをすばやく確認できる必要があります。 この情報は役に立ちます。目標を達成すると、最適化が完了するからです。

基本的なパフォーマンスのガイドライン

一般に、キャッシュされていない HTML リクエストは 100 ミリ秒未満に抑えてください。 具体的には、次のようなガイドラインが役立つ場合があります。

• ページへの要求の 70%は、100 ミリ秒未満で応答する必要があります。
• ページに対するリクエストの 25%は、100 ミリ秒～ 300 ミリ秒以内に応答を受け取る必要があります。
• ページに対する要求の 4%が 300 ミリ秒～ 500 ミリ秒以内に応答を受け取る必要があります。
• ページの要求の 1%が 500 ミリ秒～ 1000 ミリ秒以内に応答を受け取る必要があります。
• どのページも 1 秒よりも遅く応答しません。

上記の数値は、次の条件を前提としています。

• パブリッシュ環境で測定（オーサー環境に関連するオーバーヘッドがない）
• サーバー上で測定される（ネットワークオーバーヘッドを考慮しない）
• キャッシュなし（ AEM Output キャッシュや Dispatcher キャッシュを考慮しない）
• 多数の依存ファイル（HTML、JS、PDF など）を伴う複雑な要求のみ
• 他のシステム負荷なし

パフォーマンスの問題に頻繁に影響を与える問題がいくつかあります。例えば、次のような問題です。

• Dispatcher キャッシュの非効率性
• 通常の表示テンプレート内で使用されるクエリ

JVM と OS レベルの調整は、通常、パフォーマンスが大幅に向上するわけではないので、最適化サイクルの最後に実行する必要があります。

コンテンツリポジトリの構造は、パフォーマンスにも影響を与える可能性があります。 最高のパフォーマンスを得るには、コンテンツリポジトリ内の個々のノードにアタッチされている子ノードの数を原則として 1,000 個以下にする必要があります。

通常のパフォーマンス最適化の練習での最高の友達は次のとおりです。

• ：
  request.log
• コンポーネントベースのタイミング
• Java™プロファイラー。

デジタルアセットの読み込みと編集時のパフォーマンス

デジタルアセットの読み込みと編集に大量のデータが関与するので、パフォーマンスが問題になる場合があります。

パフォーマンスには次の 2 つの影響があります。

• CPU - 複数のコアがあると、トランスコーディングの際に処理がスムーズに行われます。
• ハードディスク：パラレル RAID ディスクで同じ結果を実現

パフォーマンスを向上させるには、次の点を考慮してください。

• 1 日にアップロードするアセットの数。次の式を基に概算できます。

• 編集がおこなわれる期間（通常は 1 日の長さで、国際的な操作の場合はさらに長くなります）。
• アップロードする画像の MB 単位の平均サイズ（および 1 つの画像につき生成されるレンディションのサイズ）。
• 平均データレートは次の式で算出されます。

• すべての編集の 80%は 20%の時間でおこなわれるので、ピーク時は平均データ率の 4 倍になります。 そんな演技が目標です。

パフォーマンスの監視

パフォーマンス（またはその欠如）は、ユーザーが最初に気付くものの 1 つです。ユーザーインターフェイスを持つ任意のアプリケーションと同様に、パフォーマンスが重要です。 AEMインストールのパフォーマンスを最適化するには、インスタンスの様々な属性とその動作を監視します。

パフォーマンスの監視を実行する方法について詳しくは、パフォーマンスの監視を参照してください。

パフォーマンスの問題を引き起こす問題は、その影響が見やすい場合でも、追跡が難しい場合が多くあります。

基本的な出発点は、システムが正常に動作している場合に、システムに関する十分な知識です。 環境が適切に動作するときに「見える」と「動作する」を知らない限り、パフォーマンスが低下したときに問題を見つけるのは困難です。 システムがスムーズに動作している場合は、時間を割いてシステムの調査を行い、パフォーマンス情報の収集が継続的なタスクであることを確認します。 これにより、パフォーマンスが低下した場合の比較の基礎が得られます。

次の図は、AEM コンテンツの要求のパスおよびパフォーマンスに影響を及ぼす可能性のある様々な要素を示しています。

パフォーマンスは、ボリュームと処理能力のバランスでもあります。

• ボリューム - システムが処理および提供する出力の量です。
• 処理能力 — システムがボリュームを配信する能力。

パフォーマンスは、Web チェーン全体の様々な場所で説明できます。

パフォーマンスに影響を与える原因となる機能領域がいくつかあります。

• キャッシュ
• アプリケーション（プロジェクト）コード
• 検索機能

業績に関する基本ルール

パフォーマンスを最適化する際は、次の特定のルールに留意してください。

• パフォーマンスのチューニングを各プロジェクトでおこなう​。
• 開発サイクルの早い段階で最適化しないでください。
• パフォーマンスは最も弱いリンクと同じくらい良い。
• 容量とボリュームを常に考えてください。
• 最初に重要な事項を最適化します。
• 必ず現実的な目標を設定してから最適化を実施する​。

パフォーマンスの設定

パフォーマンスを最適化するために AEM（および基盤となるリポジトリ）の特定の要素を設定できます。次に、可能性と推奨事項を示します。変更を加える前に、該当する機能を使用するかどうか、または使用方法を確認する必要があります。

検索インデックスの作成

AEM 6.0 以降、Adobe Experience Managerは Oak ベースのリポジトリアーキテクチャを使用します。

更新されたインデックス作成情報は、次の場所で確認できます。

• クエリとインデックスに関するベストプラクティス
• クエリとインデックス作成

ワークフローの同時処理

パフォーマンスを向上させるには、同時に実行するワークフロープロセスの数を制限します。 デフォルトでは、ワークフローエンジンは、Java™ VM で使用可能なプロセッサと同数のワークフローを並行して処理します。 ワークフローのステップで大量の処理リソース（RAM または CPU）が必要な場合は、それらのワークフローの一部を並行して実行する際に、使用可能なサーバーリソースに大きな負担をかけることになります。

例えば、画像（または一般的な DAM アセット）がアップロードされると、ワークフローは画像を DAM に自動的に読み込みます。 多くの場合、画像は高解像度で、処理に数百 MB のヒープを簡単に消費できます。 これらのイメージを並行して処理すると、メモリサブシステムとガベージコレクタに高い負荷がかかります。

ワークフローエンジンでは、Apache Sling のジョブキューを使用して、作業項目の処理の対応およびスケジュール設定を行います。デフォルトでは、ワークフロージョブの処理用に、Apache Sling Job Queue Configuration サービスファクトリから次のジョブキューサービスが作成されています。

• Granite Workflow Queue：ワークフローのほとんどのステップ（DAM アセットを処理するステップなど）では、Granite Granite Workflow Queue サービスを使用します。
• Granite Workflow External Process Job Queue：このサービスは、通常は外部システムへのアクセスや結果のポーリングに使用される、特殊な外部ワークフローのステップに使用します。例えば、InDesignメディア抽出プロセスのステップは、外部プロセスとして実装されます。 ワークフローエンジンでは、ポーリングの処理に外部キューを使用します。（com.day.cq.workflow.exec.WorkflowExternalProcess を参照してください）。

これらのサービスを設定して、同時に実行するワークフロープロセスの最大数を制限します。

リポジトリでの設定

サービスを設定する場合 sling:OsgiConfig ノードの使用に設定する場合は、既存のサービスの PID を探す必要があります。次に例を示します。org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Web コンソールを使用して PID を検出できます。

という名前のプロパティを設定します。 queue.maxparallel.

Web コンソールでの設定

Web コンソールを使用してこれらのサービスを設定するには、Apache Sling Job Queue Configuration サービスファクトリで既存の設定項目を特定します。

Maximum Parallel Jobs という名前のプロパティを設定します。

特定のワークフロー用のキューの設定

特定のワークフローモデルのジョブキューを作成して、そのワークフローモデルのジョブ処理を設定できるようにします。 このように、設定は特定のワークフローの処理に影響を与えますが、デフォルトの Granite のワークフローキューの設定は他のワークフローの処理を制御します。

ワークフローモデルを実行すると、特定のトピックの Sling ジョブが作成されます。 デフォルトでは、このトピックは、一般的な Granite Workflow Queue または Granite Workflow External Process Job Queue 用に設定されたトピックと一致します。

• com/adobe/granite/workflow/job*
• com/adobe/granite/workflow/external/job*

ワークフローモデルが生成する実際のジョブトピックには、モデル固有のサフィックスが含まれます。例えば、DAM アセットの更新​ワークフローモデルでは、次のトピックを含むジョブが生成されます。

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

そのため、ワークフローモデルのジョブトピックに一致するトピック用のジョブキューを作成できます。キューのパフォーマンス関連のプロパティの設定は、キュートピックに一致するジョブを生成するワークフローモデルにのみ影響を及ぼします。

次の手順では、例として DAM アセットの更新​ワークフローを使用して、ワークフロー用のジョブキューを作成します。

1. ジョブキューを作成する対象となるワークフローモデルを実行します。これにより、トピックの統計が生成されます。例えば、アセットに画像を追加して、DAM アセットの更新​ワークフローを実行します。

2. Sling ジョブコンソール（https://<host>:<port>/system/console/slingevent）をクリックします。

3. コンソールでワークフロー関連のトピックを確認します。 DAM アセットの更新では、次のトピックが見つかります。

   • com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/model
   • com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
   • com/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model

4. 各トピックに対して 1 つのジョブキューを作成します。 ジョブキューを作成するには、Apache Sling Job Queue ファクトリサービス用のファクトリ設定を作成します。

   このファクトリ設定は、Topics プロパティがワークフロージョブのトピックに一致する点を除き、ワークフローの同時処理で説明した Granite Workflow Queue と同様です。

AEM DAM アセット同期サービス

この AssetSynchronizationService は、マウントされたリポジトリ (LiveLink、Documentum®など ) からアセットを同期するために使用します。 デフォルトでは、この同期では 300 秒（5 分）ごとに定期的なチェックがおこなわれるので、マウントされたリポジトリを使用しない場合は、このサービスを無効にできます。

サービスを無効にするには、次の手順を実行します。 OSGi サービスの設定 CQ DAM Asset Synchronization Service 設定する 同期期間 ( scheduler.period) から（最低）1 年（秒単位で定義）へと変換されます。

複数の DAM インスタンス

複数の DAM インスタンスをデプロイすると、パフォーマンスの強化に役立ちます。例えば、次のような場合です。

• オーサー環境用の多数のアセットを定期的にアップロードするので、負荷が高くなっています。ここでは、別の DAM インスタンスを、作成者のサービス専用に設定できます。
• 世界中の複数の地域（例えば、米国、ヨーロッパ、アジア）に複数のチームが存在します。

その他の考慮事項は次のとおりです。

• 作成者の「処理中の作業」と発行の「最終版」を分離する
• オーサー環境の内部ユーザーを、パブリッシュ環境の外部の訪問者/ユーザー（エージェント、プレス担当者、顧客、学生など）と分離する。

品質保証のベストプラクティス

パブリッシュ環境にとって、パフォーマンスは最も重要です。 したがって、プロジェクトの実装時に、パブリッシュ環境に対しておこなうパフォーマンステストを慎重に計画し、分析する必要があります。

この節では、特にのパフォーマンステスト用のテスト概念の定義に関する問題を標準化した概要を示します 公開 環境。 この情報は、主に QA エンジニア、プロジェクトマネージャ、システム管理者に関心を持っています。

次に、公開​環境での AEM アプリケーションのパフォーマンステストへの標準化されたアプローチを説明します。このパフォーマンステストには、次の 5 つの段階が含まれます。

• 知識の検証
• 範囲の定義
• テスト方法
• パフォーマンスの目標の定義
• 最適化

制御は、テストに限定されず、必要な追加の包括的なプロセスです。

知識の検証

最初の手順は、テストを開始する前に知っておく必要がある基本情報を文書化することです。

• テスト環境のアーキテクチャ
• テストが必要な内部要素（分離と組み合わせの両方）を詳細に説明するアプリケーションマップ

アーキテクチャのテスト

パフォーマンステストに使用するテスト環境のアーキテクチャを文書化します。

計画済みの実稼動パブリッシュ環境を、Dispatcher、ロードバランサーと共に複製する必要があります。

アプリケーションマップ

アプリケーション全体のマップを作成できる明確な概要を示します（オーサー環境のテストから既にこのマップを持っている場合もあります）。

アプリケーションの内部要素を図で示し、テスト要件の概要を示します。色分けを使用することで、レポートの基礎としても機能します。

スコープ定義

通常、アプリケーションには様々な用途があります。 重要な使用例もあれば、重要でない使用例もあります。

公開時にパフォーマンステストの範囲を絞り込むには、Adobeで次の項目を定義することをお勧めします。

• 最も重要な業務上の事例
• 最も不可欠な技術上の事例

使用例の数は自分次第ですが、管理しやすい数（例：5 ～ 10）に制限する必要があります。

主要なユースケースを選択したら、主要業績評価指標 (KPI) とそれらの測定に使用するツールをケースごとに定義できます。 一般的な KPI の例を次に示します。

• 終了から終了までの応答時間
• サーブレットの応答時間
• 単一のコンポーネントの応答時間
• サービスの応答時間
• スレッドプール内のアイドルスレッドの数
• 空き接続数
• CPU や I/O アクセスなどのシステムリソース

テスト方法

この概念には、パフォーマンス目標の定義とテストに使用する 4 つのシナリオがあります。

• 単一コンポーネントのテスト
• 組み合わせコンポーネントテスト
• 運用開始中 シナリオ
• エラーのシナリオ

次の原則に基づきます。

コンポーネントのブレークポイント

• 各コンポーネントは、パフォーマンスに関連する場合に、特定のブレークポイントを持ちます。 つまり、特定のポイントに達するまで、コンポーネントは良好なパフォーマンスを示し、その後、パフォーマンスが急速に低下します。
• アプリケーションの概要をすべて把握するには、最初にコンポーネントを検証して、それぞれのブレークポイントを確認しておく必要があります。
• 読み込みテストを実行してブレークポイントを見つけるには、ある期間、ユーザー数を増やして負荷を増やします。 この負荷とコンポーネントの応答を監視することで、コンポーネントの破壊点に達したときの特定のパフォーマンス動作が発生します。 ポイントは、1 秒あたりの同時トランザクションの数と、同時ユーザーの数（コンポーネントがこの KPI に影響を受ける場合）で評価できます。
• この情報は、改善のためのベンチマークとして機能し、使用される測定の効率を示し、テストシナリオの定義に役立ちます。

トランザクション

• トランザクションという用語は、ページ自体とそれ以降のすべての呼び出しを含む、完全な Web ページのリクエストを表すために使用されます。 つまり、ページリクエスト、任意のAJAX呼び出し、画像、その他のオブジェクトです ドリルダウンをリクエスト.
• 各リクエストを完全に分析するには、呼び出しスタックの各要素を表し、それぞれの平均処理時間の合計を示します。

パフォーマンス目標の定義

範囲と関連する KPI を定義した後、特定のパフォーマンス目標が設定されます。 このプロセスでは、テストシナリオをターゲット値と共に策定します。

平均条件とピーク条件の両方でパフォーマンスをテストします。 また、運用開始のシナリオテストを実施して、Web サイトが初めて利用可能になったときに、Web サイトに対する関心の高まりに対応できるようにする必要があります。

既存の Web サイトから収集した任意のエクスペリエンスや統計も、将来の目標の決定に役立ちます。 例えば、実際の Web サイトからのトラフィックが最も多い場合などです。

単一コンポーネントのテスト

重要なコンポーネントは、平均条件とピーク条件の両方でテストする必要があります。

どちらの場合も、事前に定義された数のユーザーがシステムを使用している場合に、1 秒あたりのトランザクションの予想数を定義できます。

コンポーネント	テストタイプ	いいえ。/ユーザー	Tx/秒（想定）	Tx/秒（テスト済み）	説明
ホームページのシングルユーザー	平均	1	1
	ピーク	1	3
ホームページ 100 人のユーザー	平均	100	3
	ピーク	100	3

組み合わせコンポーネントのテスト

組み合わせてコンポーネントをテストすると、アプリケーションの動作がより詳細に反映されます。 再び平均条件とピーク条件をテストする必要があります。

シナリオ	コンポーネント	いいえ。/ユーザー	Tx/秒（想定）	Tx/秒（テスト済み）	説明
混合平均	ホームページ	10	1
	検索	10	1
	ニュース	10	2
	イベント	10	1
	アクティベーション	10	3		オーサー動作のシミュレーション。
混合ピーク	ホームページ	100	5
	検索	50	5
	ニュース	100	10
	イベント	100	10
	アクティベーション	20	20		オーサー動作のシミュレーション。

運用中のテスト

Web サイトが公開されてからの最初の数日間は、より高い関心レベルを期待できます。 このシナリオは、テストするピーク値よりも大きくなります。 Adobeでは、運用開始のシナリオをテストして、システムがこの状況に対応できることを確認することをお勧めします。

シナリオ	テストタイプ	いいえ。/ユーザー	Tx/秒（想定）	Tx/秒（テスト済み）	説明
運用開始のピーク	ホームページ	200	20
	検索	100	10
	ニュース	200	20
	イベント	200	20
	アクティベーション	20	20		オーサー動作のシミュレーション。

エラーシナリオテスト

エラーシナリオをテストし、システムが正しく正しく対応していることを確認します。 エラー自体の処理方法だけでなく、エラーがパフォーマンスに与える影響についても説明します。 次に例を示します。

• ユーザーが検索ボックスに検索用語を入力しようとするとどうなるか
• 検索用語が一般的すぎて、返される結果の数が非常に多い場合はどうなるか

これらのテストを策定する際は、すべてのシナリオが定期的に発生するわけではないことを忘れないでください。 ただし、システム全体に対する影響は重要です。

エラーのシナリオ	エラータイプ	いいえ。/ユーザー	Tx/秒（想定）	Tx/秒（テスト済み）	説明
検索コンポーネントのオーバーロード	グローバルワイルドカード（アスタリスク）を検索	10	1		*** のみが検索されます。
	ストップワード	20	2		ストップワードの検索。
	空の文字列	10	1		空の文字列の検索。
	特殊文字	10	1		特殊文字を検索しています。

耐久テスト

特定の問題は、システムが稼働してから数時間または数日間の間に発生する場合にのみ発生します。 持久力テストは、必要な期間に渡る一定の平均負荷をテストするために使用します。 その後、パフォーマンスの低下を分析できます。

シナリオ	テストタイプ	いいえ。/ユーザー	Tx/秒（想定）	Tx/秒（テスト済み）	説明
耐久テスト（72 時間）	ホームページ	10	1
	検索	10	1
	ニュース	20	2
	イベント	10	1
	アクティベーション	1	3		オーサー動作のシミュレーション。

最適化

実装の後の段階で、パフォーマンス目標を満たし、最大化するようにアプリケーションを最適化します。

実施した最適化をすべてテストして、次の点を確認してください。

• 機能に影響を及ぼさない
• リリース前に負荷テストを実施して検証済みである

ロードジェネレーション、パフォーマンス監視、結果分析に役立つ様々なツールを利用できます。 これらのツールの一部を次に示します。

• JMeter
• Load Runner
• InfraRED
• Java™ Interactive Profile

最適化後、再度テストして影響を確認します。

レポート

継続的なレポートにより、すべてのユーザーが状況を把握できます。 前述のように、色分けでは、アーキテクチャマップをこの状態に使用できます。

すべてのテストが完了したら、次の情報を報告します。

• 発生した重大なエラー
• より多くの調査が必要な重要でない問題
• テスト中の想定事項
• テストから得られた推奨事項

Dispatcher の使用時のパフォーマンスの最適化

この Dispatcher は、Adobeのキャッシュやロードバランシングを行うツールです。 Dispatcher を使用する場合は、キャッシュパフォーマンスを確保するために Web サイトの最適化を検討してください。

Dispatcher には、Web サイトでパフォーマンスを活用する場合にパフォーマンスを最適化するために使用できる、いくつかの組み込みメカニズムが用意されています。 この節では、キャッシュのメリットを最大限に活用するために Web サイトをデザインする方法について説明します。

Dispatcher のキャッシュ率の計算

キャッシュ率の数式では、システムに入ってくる要求の合計数の中から、キャッシュによって処理される要求の割合を推定します。 キャッシュ率を計算するには、次の情報が必要です。

• 要求の総数。この情報は、Apache の access.log で確認できます。詳しくは、 公式の Apache ドキュメント.

• パブリッシュインスタンスが提供した要求の数。 この情報は、インスタンスの request.log で確認できます。詳しくは、request.log の解釈およびログファイルの検索を参照してください。

キャッシュ率の計算式は次のとおりです。

• 要求の総数からパブリッシュにおける要求の数を​差し引き、それを要求の総数で​割ります。

例えば、要求の合計数が129491で、パブリッシュインスタンスが提供する要求の数が58959の場合、キャッシュの比率は次のようになります。 (129491 - 58959)/129491= 54.5%.

1 対 1 のパブリッシャーと Dispatcher の組み合わせがない場合は、すべての Dispatcher とパブリッシャーからのリクエストを一緒に追加して、正確な測定をおこなうことができます。 関連トピック 推奨されるデプロイメント.

一貫したページエンコーディングの使用

Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。 Dispatcher 上で応答ヘッダーをキャッシュしない場合、ヘッダーにページエンコーディング情報を格納していると、問題が発生する可能性があります。 この場合、Dispatcher がキャッシュからページを提供すると、ページで Web サーバーのデフォルトのエンコーディングが使用されます。 この問題を回避する方法は 2 つあります。

• 1 つのエンコーディングのみを使用する場合は、Web サーバーで使用されるエンコーディングが、AEM Web サイトのデフォルトのエンコーディングと同じであることを確認します。
• エンコーディングを設定するには、 <META> タグをHTML head セクションに表示されます。

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

URL パラメーターの使用回避

可能な限り、キャッシュするページの URL パラメーターは使用しないでください。 例えば、ピクチャーギャラリーがある場合、次の URL はキャッシュされません (Dispatcher が 適切に設定):

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

ただし、次のように、これらのパラメーターをページ URL に配置できます。

www.myCompany.com/pictures/gallery.christmas.1.html

URL でカスタマイズ

ユーザーがフォントサイズ（またはその他のレイアウトのカスタマイズ）を変更できるようにする場合は、様々なカスタマイズが URL に反映されていることを確認します。

例えば、cookie はキャッシュされないので、フォントサイズを cookie（または同様のメカニズム）に格納した場合、キャッシュされたページのフォントサイズは保持されません。 その結果、Dispatcher は任意のフォントサイズのドキュメントをランダムに返します。

URL にフォントサイズをセレクターとして含めると、次の問題を回避できます。

www.myCompany.com/news/main.large.html

タイトルとして使用されている画像ファイルの無効化

ページのタイトルや他のテキストを画像としてレンダリングする場合は、ページ上のコンテンツの更新時にファイルが削除されるように、ファイルを保存することをお勧めします。

1. 画像ファイルを、ページと同じフォルダーに配置します。

2. 画像ファイルに次の命名形式を使用します。

   <page file name>.<image file name>

例えば、file myPage.title.gif にページ のタイトル myPage.html を格納できます。ページが更新されると、このファイルは自動的に削除されるので、ページタイトルに対する変更はキャッシュに自動的に反映されます。

ナビゲーションに使用された画像ファイルの無効化

ナビゲーションエントリに画像を使用する場合、この方法はタイトルと同じですが、少し複雑です。 すべてのナビゲーション画像をターゲットページと共に保存します。 通常とアクティブに 2 つの画像を使用する場合は、次のスクリプトを使用できます。

• 通常どおりページを表示するスクリプト。
• 「.normal」リクエストを処理し、通常の画像を返すスクリプト。
• 「.active」リクエストを処理し、アクティベートされた画像を返すスクリプト。

コンテンツの更新でこれらの画像とページが確実に削除されるように、ページと同じ名前のハンドルでこれらの画像を作成することが重要です。

変更されていないページの場合、画像はキャッシュに残りますが、ページ自体は自動的に無効化されます。

パーソナライズ機能

パーソナライズ機能は必要な場所に制限することをお勧めします。その理由を次に示します。

• 自由にカスタマイズ可能な開始ページを使用する場合は、ユーザーが要求するたびにそのページを構成する必要があります。
• これに対して、10 の異なる開始ページを選択できる場合は、各ページをキャッシュして、パフォーマンスを向上させることができます。

（例えば）ユーザーの名前をタイトルバーに入れて各ページをパーソナライズすると、パフォーマンスに影響を与えます。

1 つのページでの制限付きコンテンツと公開コンテンツの混在に関して、Dispatcher でのサーバー側インクルードの使用方法と、ブラウザーでの Ajax を使用するクライアント側インクルードの方法を検討します。

スティッキー接続

スティッキー接続 1 人のユーザーのドキュメントがすべて同じサーバー上で構成されていることを確認します。 ユーザーがこのフォルダーを離れ、その後戻った場合、接続は維持されます。 Web サイトのスティッキー接続を必要とするすべてのドキュメントを保持するには、1 つのフォルダーを定義します。 他のドキュメントを含めないようにしてください。 このシナリオは、パーソナライズされたページとセッションデータを使用する場合に、ロードバランシングに影響します。

MIME タイプ

ブラウザーがファイルの種類を判断する方法は 2 つあります。

1. 拡張子別 ( 例： .html, .gif、および .jpg) をクリックします。
2. サーバーがファイルと共に送信する MIME タイプ。

ほとんどのファイルでは、MIME タイプがファイル拡張子に暗黙で指定されます。 つまり

1. 拡張子別 ( 例： .html, .gif、および .jpg) をクリックします。
2. サーバーがファイルと共に送信する MIME タイプ。

ファイル名に拡張子がない場合は、プレーンテキストとして表示されます。

Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。 Dispatcher で応答ヘッダーをキャッシュしない場合、MIME タイプは HTTP ヘッダーの一部になります。 つまり、AEM アプリケーションから返されるファイルが、認識されたファイル拡張子を持たず、代わりに MIME タイプに依存する場合は、ファイルが正しく表示されない可能性があります。

ファイルが適切にキャッシュされるようにするには、次のガイドラインに従います。

• ファイルの拡張子が常に適切であることを確認します。
• 次のような URL を持つ汎用のファイル提供スクリプトは避けます。 download.jsp?file=2214. ファイル仕様を含む URL を使用するには、スクリプトを書き換えます。 前の例では、次の書き換えがおこなわれます。 download.2214.pdf.

バックアップのパフォーマンス

この節では、AEMのバックアップのパフォーマンスと、バックアップアクティビティがアプリケーションのパフォーマンスに与える影響を評価するために使用される一連のベンチマークについて説明します。AEMのバックアップは、実行中にシステムに大きな負荷を与え、Adobeはこの影響と、これらの影響を調整しようとするバックアップ遅延設定の影響を測定します。 目的は、現実的な構成でのバックアップの期待されるパフォーマンスと実稼働データの量に関する参照データを提供し、計画されたシステムのバックアップ時間を見積もる方法に関するガイダンスを提供することです。

参照環境

物理システム

このドキュメントで報告された結果は、次の設定を使用した参照環境で実行されたベンチマークから取得されました。この設定は、データセンターでの一般的な実稼動環境に似ています。

• HP ProLiant DL380 G6、8 CPUx 2.533 GHz
• シリアル接続 SCSI 300 GB、10,000 RPM ドライブ
• ハードウェア RAID コントローラRAID0+5 アレイの 8 台のドライブ
• VMware イメージ CPU x 2 Intel Xeon® E5540 @ 2.53 GHz
• Red Hat® Linux® 2.6.18-194.el5;Java™ 1.6.0_29
• 単一のオーサーインスタンス

このサーバのディスクサブシステムは高速で、本番サーバで使用される可能性のある高パフォーマンス RAID 構成を表します。 バックアップのパフォーマンスはディスクのパフォーマンスに影響を受ける可能性があり、この環境の結果は高速 RAID 構成でのパフォーマンスを反映します。 VMWare イメージは、RAID アレイ上のローカルディスクストレージに物理的に存在する 1 つの大きなディスクボリュームを持つように構成されます。

AEMの設定により、リポジトリとデータストアが、オペレーティングシステムとAEMソフトウェアと共に同じ論理ボリュームに配置されます。 バックアップのターゲットディレクトリも、この論理ファイルシステム上に存在します。

データ量

次の表に、バックアップベンチマークで使用されるデータボリュームのサイズを示します。 最初のベースラインコンテンツをインストールした後、既知の量のデータを追加して、バックアップするコンテンツのサイズを増やします。 バックアップは、コンテンツの大幅な増加と、1 日に何が生成されるかを示すために、特定の増分で作成されます。 コンテンツ（ページ、画像、タグ）の配布は、ほぼ現実的な実稼動用アセットの構成に基づいています。 ページ、画像、タグは、子ページの数が最大 800 に制限されています。 各ページには、タイトル、Flash、テキスト/画像、ビデオ、スライドショー、フォーム、テーブル、クラウド、カルーセルの各コンポーネントが含まれます。 画像は、400 個の一意のファイルサイズのプール（37 KB から 594 KB にアップロードされます）からアップロードされます。

コンテンツ	ノード数	ページ	画像	タグ
ベースインストール	69 610	562	256	237
増分バックアップ用の小さなコンテンツ		+100	+2	+2
フルバックアップ用の大きなコンテンツ		+10 000	+100	+100

バックアップのベンチマークは、それぞれにコンテンツセットを追加して繰り返されます。

ベンチマークのシナリオ

バックアップのベンチマークは 2 つの主要なシナリオに対応しています。1 つはシステムでアプリケーションによる負荷が大きい場合のバックアップで、もう 1 つはシステムがアイドル状態の場合のバックアップです。一般的には、できるだけ AEM がアイドル状態の場合にバックアップを実行することをお勧めしますが、システムに負荷がかかっている際にバックアップを実行しなければならない場合もあります。

• アイドル状態 - バックアップは、AEM 上の他のアクティビティを使用せずに実行されます。
• 負荷下 - オンラインプロセスから 80 ％の負荷がシステムにかかっている状態でバックアップが実行されます。負荷に対する影響を確認するためにバックアップ遅延を変更しました。

バックアップ時間と生成されるバックアップのサイズは AEM サーバーのログから取得します。通常は、AEM がアイドル状態であるオフタイム（深夜など）にバックアップのスケジュールを設定することをお勧めします。このシナリオは、推奨されるアプローチを表しています。

Load は、作成されたページ、削除されたページ、トラバーサル、およびページのトラバーサルとクエリからのほとんどの負荷を含むクエリで構成されます。 多数のページを追加または削除すると、ワークスペースのサイズが継続的に増加し、バックアップが完了しなくなります。 スクリプトで使用される読み込みの分布は、75%のページトラバーサル、24%のクエリ、1%のページ作成です（ネストされたサブページのない単一レベル）。 アイドルシステムでの 1 秒あたりのピーク平均トランザクション数は、4 つの同時スレッドを使用して達成されます。これは、負荷の下でバックアップをテストする際に使用されます。

このアプリケーションの負荷の有無によるパフォーマンスの違いによって、バックアップのパフォーマンスに対する負荷の影響を予測できます。 1 時間あたりのトランザクションのシナリオのスループットを、同時バックアップを継続して行う場合と行わない場合、および異なる「バックアップ遅延」設定で動作するバックアップと比較すると、バックアップのアプリケーションスループットへの影響が見られます。

• 遅延設定 — いくつかのシナリオでは、バックアップ遅延設定も変更され、10 ミリ秒（デフォルト）、1 ミリ秒、0 ミリ秒の値を使用して、この設定がバックアップのパフォーマンスに与えた影響を調べました。
• バックアップの種類 — すべてのバックアップは、tar コマンドが直接使用された場合を除き、zip を作成せずにバックアップディレクトリに対して行われたリポジトリの外部バックアップでした。 増分バックアップを zip ファイルに作成できないので、また、以前の完全バックアップが zip ファイルの場合は、バックアップディレクトリ方式が本番環境で最も頻繁に使用されます。

結果のまとめ

バックアップ時間とスループット

これらのベンチマークの主な結果は、バックアップの種類と全体的なデータ量の関数に応じてバックアップ時間がどの程度変化するかを示すことです。 次の図は、合計ページ数の関数として、デフォルトのバックアップ構成を使用して取得したバックアップ時間を示しています。

アイドル状態のインスタンスのバックアップ時間は、フル・バックアップまたは増分バックアップに関係なく、1 秒あたり平均 0.608 MB/秒で、かなり一貫しています（下図を参照）。 バックアップ時間は、バックアップされるデータ量の関数に過ぎません。 フル・バックアップの完了に要する時間は、合計ページ数と共に明らかに増加します。 増分バックアップの完了に要する時間も合計ページ数で増加しますが、かなり低い速度で進みます。 増分バックアップの完了に要する時間は、バックアップされるデータ量が比較的少ないため、はるかに短くなります。

生成されるバックアップのサイズは、バックアップの完了に要する時間の主な決定要因です。 次のグラフは、最終的なバックアップ・サイズの関数としての所要時間を示しています。

この図は、増分バックアップとフル・バックアップの両方が、Adobeがスループットとして測定できるシンプルなサイズと時間のパターンに従うことを示しています。 アイドル状態のインスタンスのバックアップ時間は、ベンチマーク環境でのフルバックアップまたは増分バックアップに関係なく、1 秒あたり平均 0.61 MB/秒でかなり一貫しています。

バックアップ遅延

バックアップ遅延パラメータが提供され、バックアップが本番ワークロードに影響を与える可能性のある範囲を制限します。 このパラメータは、待ち時間をミリ秒単位で指定します。この値は、ファイル単位でバックアップ操作に割り当てられます。 全体的な効果は、影響を受けるファイルのサイズによって一部異なります。 MB/秒でバックアップのパフォーマンスを測定すると、バックアップに対する遅延の影響を比較するのに適した方法が得られます。

• 通常のアプリケーションの負荷と同時にバックアップを実行すると、通常の負荷のスループットに悪影響を与えます。
• 影響は軽微（5 %程度）または有意で、スループットが 75 %も低下する場合があります。 多くの場合、アプリケーションによって異なります。
• バックアップが CPU に高い負荷をかけることはありません。そのため、CPU 負荷が高い実稼働のワークロードは、I/O 負荷が高いワークロードよりもバックアップから受ける影響が少なくなります。

比較のために、同じリポジトリファイルをバックアップするためにファイルシステムのバックアップ (「tar」) を使用して取得したスループット。 tar のパフォーマンスは同等ですが、遅延が 0 に設定されたバックアップよりも若干高くなります。 遅延を小さく設定しても、バックアップのスループットが大幅に低下し、10 ミリ秒のデフォルトの遅延により、スループットが大幅に低下します。 アプリケーションの全体的な使用率が低い場合や、アプリケーションがアイドル状態の場合にバックアップをスケジュールする場合は、デフォルト値を下回る遅延を減らして、バックアップをより迅速に実行できます。

継続的なバックアップのアプリケーション・スループットの実際の影響は、アプリケーションとインフラストラクチャの詳細によって異なります。 遅延値の選択は、アプリケーションの経験的な分析によって行う必要がありますが、バックアップを可能な限り迅速に完了できるように、できる限り小さな値を選択する必要があります。 遅延値の選択とアプリケーションのスループットへの影響には弱い相関があるので、遅延を選択すると全体的なバックアップ時間を短くして、バックアップ全体の影響を最小限に抑える必要があります。 8 時間かかり、スループットに —20%の影響を与えるバックアップは、完了までに 2 時間かかり、スループットに —30%の影響を与える場合よりも全体的な影響が大きくなる可能性があります。

参照

• 管理 — バックアップと復元
• 管理 - 処理能力とボリューム