パフォーマンスの最適化

Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。当然、応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。達成可能かつ維持可能な値を定義したことを確認したうえで、その値に基づいて Web サイトのパフォーマンスを監視すると、潜在的な問題が発生しつつあるときに、その状況を検知することができます。

オーサー環境とパブリッシュ環境では、対象となる利用者の特性が異なるので、目指す応答時間が異なります。

オーサー環境

この環境は、コンテンツを入力および更新する作成者によって使用されます。そのため、少人数のユーザー向けに構築されている必要があります。各ユーザーは、コンテンツページとそのページ上の個々の要素を更新するときに、パフォーマンスに重点を置いた多数の要求を生成します。

パブリッシュ環境

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

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

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

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

これらのルールは、大まかには、Webプロジェクト全般に適用され、プロジェクト管理者やシステム管理者に関連しており、起動時にプロジェクトのパフォーマンス上の課題に直面しないようにします。

最適化の計画

パフォーマンスの最適化フェーズには、プロジェクト全体の作業のうち 10 ％程度を割くことが望ましいと考えられます。もちろん、パフォーマンスの最適化に必要な作業の量は、プロジェクトの複雑さや開発チームの経験によって異なります。プロジェクトによっては、そこまで時間を割く必要がなかったという結果になる可能性もありますが、パフォーマンスの最適化には必ずこの程度の手間を見込んで計画を立てるのが実用的です。

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

システムが本番に入っても、パフォーマンスの最適化は終わりません。むしろ、サービスを開始して「現実の」システム負荷が判明した後にこそ、再調整をおこなうように計画を立てておくことが重要です。

時が経つにつれて、システム負荷は変化し、システムのパフォーマンスプロファイルは遷移していきます。6 ～ 12 ヶ月おきにパフォーマンスの「チューンアップ」または「ヘルスチェック」を続けていくようにしてください。

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

Web サイトの運用を開始した後で、パフォーマンスの問題が発生することが判明した場合、理由は 1 つしかありません。それは、負荷とパフォーマンスのテストで実際の状況に十分近いシミュレーションができていなかったということです。

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

適切な目標設定

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

どうすれば適切で確実性の高いパフォーマンス目標を設定できるかというのは非常に難しい問題です。多くの場合、最も参考になるのは、類似性がある Web サイト（例えば、前身となったサイト）で採取した実際のログやベンチマーク結果の情報です。

妥当性の維持

ボトルネックの最適化は 1 つずつ適用していくことが重要です。ある対策の影響を検証しないうちに別の作業も並行しておこなうと、どの最適化対策が実際に効果を発揮したのかわからなくなります。

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

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

これはつまり、最適化作業を実施する開発者には、最適化目標が達成された場合にその事実をすぐ把握できる手段が必要だということです。目標の達成は最適化作業の終了を意味するだけに、いつ達成されたかという情報には大きな価値があります。

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

大まかな目安として、キャッシュされていない HTML 要求の応答時間は 100 ms 未満に抑えます。より具体的には次のようなガイドラインに従うとよいでしょう。

• ページ要求件数の 70 ％に対して 100 ms 未満で応答する。
• ページ要求件数の 25 ％に対して 100 ～ 300 ms の範囲で応答する。
• ページ要求件数の 4 ％に対して 300 ～ 500 ms の範囲で応答する。
• ページ要求件数の 1 ％に対して 500 ～ 1000 ms の範囲で応答する。
• ページ要求への応答時間が 1 秒を超えることはない。

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

• 公開時に測定されます（オーサリング環境に関連するオーバーヘッドはありません）。
• サーバー上で測定（ネットワークオーバーヘッドなし）
• キャッシュされない(AEM出力キャッシュなし、Dispatcherキャッシュなし)
• 多くの依存関係を持つ複雑な項目（HTML、JS、PDFなど）の場合のみ。
• システムに他の負荷がない

パフォーマンスに影響しやすい要因はいくつかありますが、それらは主に次に関連する問題です。

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

JVM および OS レベルの調整は、通常、大幅なパフォーマンス向上には結び付かないので、最適化サイクルの最後に実行すれば十分です。

コンテンツリポジトリの構造化の方法はパフォーマンスにも影響を及ぼす可能性があります。最適なパフォーマンスを確保するために、コンテンツリポジトリ内の個々のノードに接続される子ノードの数は、通常 1,000 個未満にする必要があります。

通常のパフォーマンス最適化では、次の要素を使用します。

• request.log
• コンポーネントベースのタイミング
• 最後に、少なくともJavaプロファイラー。

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

デジタルアセットの読み込み時と編集時には大量のデータが関係してくるので、パフォーマンスが問題になります。

この場合、パフォーマンスに影響を及ぼす要素は次の 2 つです。

• CPU — 複数のコアを使用すると、トランスコード時の作業をスムーズに行うことができます。
• ハードディスク - 並列の RAID ディスクを使用すると、同じ効果がもたらされます。

パフォーマンスを向上するには、次の点を考慮します。

• 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のワークフローキュー：DAMアセットを処理するワークフローステップなど、ほとんどのワークフローステップでは、 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 Workflow Queue の設定はその他のワークフローの処理を制御します。

ワークフローモデルの実行時には、特定のトピック用の 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 ファクトリサービス用のファクトリ設定を作成します。

   ファクトリ設定は、 ワークフローの同時処理で説明されているGraniteワークフローキューに似ていますが、Topicsプロパティがワークフロージョブのトピックと一致する点が異なります。

AEM DAM Asset Synchronization Service

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

この処理をおこなうには、OSGi サービスである CQ DAM Asset Synchronization Service を設定して、同期期間（scheduler.period）を（最低）1 年（秒数で定義）にします。

複数の DAM インスタンス

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

• オーサー環境用に多数のアセットを定期的にアップロードするので、負荷が高くなります。ここでは、別のDAMインスタンスを作成者のサービス専用にすることができます。
• 世界中の場所（米国、ヨーロッパ、アジアなど）に複数のチームがあります。

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

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

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

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

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

次の表は、Publish​環境でのAEMアプリケーションのパフォーマンステストに対する標準化されたアプローチを示しています。 これには、次の5つのフェーズが含まれます。

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

包括的な追加のプロセスとして「制御」があります。これは必要なプロセスですが、テストに限定されるものではありません。

知識の検証

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

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

テスト用のアーキテクチャ

パフォーマンステストに使用するテスト環境のアーキテクチャを明確に文書化してください。

計画した実稼働のパブリッシュ環境、Dispatcher およびロードバランサーを再現する必要があります。

アプリケーションマップ

概要を明確にするために、アプリケーション全体のマップを作成できます（オーサー環境におけるテストからこの情報を入手できる可能性があります）。

アプリケーションの内部要素を図で表すことで、テスト要件の概要を説明できます。色分けしたマップは、レポートの基盤としての役割も果たします。

範囲の定義

通常、アプリケーションは様々な使用事例に対応しています。これらの事例は非常に重要なものと、それほど重要でないものに分けられます。

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

• 最も重要なビジネスの使用例
• 最も重要な技術的使用例

事例の数は状況に応じて異なりますが、管理しやすい数（例えば、5 ～ 10）に制限してください。

主要な事例を選択したら、測定に使用する重要業績評価指標（KPI）とツールを事例ごとに定義できます。一般的な KPI の例を次に示します。

• エンドツーエンドの応答時間
• サーブレットの応答時間
• 単一のコンポーネントに対する応答時間
• サービスに対する応答時間
• スレッドプール内のアイドル状態のスレッドの数
• 自由な接続の数
• システムリソース（CPU、I/O アクセスなど）

テスト方法

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

• 単一のコンポーネントのテスト
• 組み合わされたコンポーネントのテスト
• 運用開始のシナリオ​**
• エラーのシナリオ

基盤となる原則は次のとおりです。

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

• 各コンポーネントには、パフォーマンスに関連する特定のブレークポイント（限界点）があります。つまり、特定のポイントに到達するまではコンポーネントのパフォーマンスが良好で、そのポイントを超えるとパフォーマンスが急激に低下します。
• アプリケーションの概要をすべて把握するには、最初にコンポーネントを検証して、それぞれのブレークポイントを確認しておく必要があります。
• ブレークポイントを検出するために、負荷テストを実施できます。このテストでは、ある特定の期間にわたってユーザー数を増やして負荷を上げていきます。この負荷およびコンポーネントの応答を監視することにより、コンポーネントのブレークポイントに到達したときの特定のパフォーマンスの動作を確認できます。このポイントは、1 秒あたりの同時トランザクションの数および同時ユーザーの数によって制限されます（コンポーネントに対するこの KPI の影響度が高い場合）。
• この情報は引き続き改善のためのベンチマークとなり、使用される測定の効率を示して、テストシナリオの定義に役立てることができます。

トランザクション

• トランザクションという用語は、完全な Web ページの要求を表すために使用します。この要求には、ページ自体および後続のすべての呼び出し（ページ要求、AJAX 呼び出し、画像およびその他のオブジェクト）が含まれます。要求のドリルダウン
• 各要求をすべて分析するために、コールスタックの各要素を表してから、各要求の平均処理時間の合計を求めることができます。

Defining the Performance Goals

範囲と関連する KPI の定義が完了したら、パフォーマンスの目標を設定できます。この作業には、テストシナリオおよびターゲットとなる値の策定が含まれます。

平均時とピーク時の両方の条件下でパフォーマンスをテストしてください。また、運用開始のシナリオのテストを実施して、運用開始時の Web サイトに対する関心の増加に対応できるようにする必要があります。

既存の Web サイトから収集したエクスペリエンス（統計）も将来の目標を決める際に役立ちます。例えば、本番の Web サイトからの上位のトラフィックなどです。

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

平均時とピーク時の両方の条件下で、不可欠なコンポーネントをテストする必要があります。

どちらの場合も、定義済みの数のユーザーがシステムを使用する際の 1 秒あたりのトランザクションの予想数を定義できます。

コンポーネント	テストの種類	いいえ。ユーザー数	トランザクション数/秒（予想）	トランザクション数/秒（テスト済み）	説明
ホームページ：1 ユーザー	平均	1	1
	ピーク時	1	3
ホームページ：100 ユーザー	平均	100	1
	ピーク時	100	1

組み合わされたコンポーネントのテスト

組み合わされたコンポーネントをテストすると、アプリケーションの動作がより忠実に反映されます。この場合も、平均時とピーク時の両方の条件下でテストを実施する必要があります。

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

運用開始のテスト

Web サイトの運用開始後の最初の数日は、関心レベルの増加が予測されます。この値はおそらく、現在テストを進めているピーク時の値よりも大きくなります。運用開始のシナリオをテストして、システムがこの状況に対応できるかどうかを確認しておくことを強くお勧めします。

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

エラーのシナリオのテスト

システムによる対応が正しく適切におこなわれるように、エラーのシナリオもテストする必要があります。エラー自体を処理する方法だけでなく、その方法がパフォーマンスに及ぼす可能性のある影響も確認します。次に例を示します。

• ユーザーが検索ボックスに無効な検索語句を入力しようとした場合の影響
• 検索語句が一般的すぎて、過剰な数の結果が返された場合はどうなりますか。

このようなテストの策定時には、すべてのシナリオが定期的に発生するわけではない点に注意してください。ただし、テストがシステム全体に及ぼす影響は重要です。

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

耐久テスト

システムを継続的な期間（数時間または数日）実行した後にのみ発生する問題があります。耐久テストは、必要とされるある一定の期間にわたる、継続的な平均負荷を確認するために使用します。テストの後でパフォーマンスの低下を分析できます。

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

最適化

実装の後半の段階では、アプリケーションを最適化して、パフォーマンスの目標を達成または最大化する必要があります。

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

• 機能に影響を与えない
• リリース前に負荷テストで検証済み

負荷の生成、パフォーマンスの監視および結果の分析に役立つ様々なツールが用意されています。

• JMeter
• ロードランナー
• Determyne InsideApps
• InfraRED
• Java Interactive Profile
• その他の様々なツール

最適化の後にもう一度テストを実施して、影響を確認する必要があります。

レポート

アーキテクチャマップを色分けして使用すると、前述したように、すべてのユーザーに状態を通知するために、継続的なレポート作成が必要になります。

すべてのテストが完了すると、次の項目についてレポートできます。

• 重大なエラーが発生した場合
• さらなる調査が必要な重要でない問題
• テスト中に仮定した場合
• テストから生じる推奨事項

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

ディスパッチャーはアドビのキャッシュ／ロードバランシングツールです。ディスパッチャーを使用する場合は、キャッシュパフォーマンスを確保するために Web サイトの最適化を検討する必要があります。

Dispatcher には、Web サイトで活用するとパフォーマンスが最適化される、複数の組み込みのメカニズムが用意されています。ここでは、キャッシュのメリットを最大化するように Web サイトをデザインする方法について説明します。

Dispatcher のキャッシュ率の計算

キャッシュ率の計算式では、システムが受け取った要求の総数のうちキャッシュによって処理された要求の割合（％）が概算されます。キャッシュ率を計算するには、次の情報が必要です。

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

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

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

• （要求の総数​から​を引いた発行要求数） を要求の総数で割った値。

例えば、要求の総数が 129,491 であり、パブリッシュインスタンスによって処理された要求の数が 58,959 である場合、キャッシュ率は (129,491 - 58,959)/129,491 = 54.5％​です。

パブリッシャーと Dispatcher が 1 対 1 のペアではない場合、正確な測定値を得るには、すべての 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>

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

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

ナビゲーションエントリ用の写真を使用する場合の方法は、タイトルを使用する場合と基本的に同じですが、若干複雑になります。すべてのナビゲーション画像をターゲットページと共に格納します。通常用とアクティブ用の 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タイプに依存する場合、これらのファイルが正しく表示されない可能性があります。

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

• ファイルに必ず適切な拡張子を含めます。
• download.jsp?file=2214などのURLを持つ汎用のファイル提供スクリプトは避けます。ファイル仕様を含むURLを使用するスクリプトを書き直します。 前の例では、download.2214.pdfとなります。

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

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

参照用の環境

物理システム

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

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

このサーバーのディスクサブシステムは非常に高速であり、実稼働サーバーで使用可能な高性能 RAID 設定を代表するものです。バックアップのパフォーマンスはディスクのパフォーマンスの影響を受けやすく、この環境の結果は非常に高速な RAID 設定におけるパフォーマンスを反映します。VMWare イメージは、RAID アレイ上のローカルディスクストレージに単一の大きなディスクボリュームを物理的に配置するように設定されます。

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

データボリューム

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

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

バックアップベンチマークは、繰り返しのたびに追加されるコンテンツセットと共に繰り返されます。

ベンチマークのシナリオ

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

• Idle State ：バックアップは、AEM上で他のアクティビティを使用せずに実行されます。
• 「Load 」の下：バックアップは、オンライン・プロセスの負荷が80%未満の状態で実行されます。負荷に対する影響を確認するためにバックアップ遅延を変更しました。

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

負荷を構成するのは、ページの作成／削除、移動およびクエリーです。負荷の大部分はページの移動とクエリーによるものです。大量のページを追加および削除することでワークスペースのサイズが継続的に増加し、バックアップを完了できなくなります。スクリプトが使用する負荷の分散により、75 ％がページの移動、24 ％がクエリー、1 ％がページの作成に割り当てられます（ネストされたサブページのない単一のレベル）。アイドル状態のシステムでピーク時の 1 秒あたりの平均トランザクション数を実現するには 4 つの同時スレッドを使用します。これは、負荷状態でのバックアップのテスト時に使用されます。

バックアップのパフォーマンスに負荷が及ぼす影響は、このアプリケーションによる負荷がある状態とない状態のパフォーマンスの差で見積もることができます。アプリケーションのスループットにバックアップが及ぼす影響は、同時バックアップを実行している状態と実行していない状態でのこのシナリオのトランザクションのスループット（1 時間あたり）と、異なる「バックアップ遅延」設定を使用してバックアップを実行している状態でのトランザクションのスループット（1 時間あたり）を比較して特定されます。

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

結果のまとめ

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

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

アイドル状態のインスタンスでのバックアップ時間は、フルバックアップか増分バックアップかに関係なく平均 0.608 MB/s でほぼ一定です（下の図を参照）。バックアップ時間は単にバックアップされるデータ量の関数です。フルバックアップの完了に要する時間は、合計ページ数が増加すると明らかに長くなります。増分バックアップの完了に要する時間も合計ページ数が増加すると長くなりますが、はるかに低い割合です。増分バックアップの完了に要する時間が短いのは、バックアップ対象のデータが比較的少量であるためです。

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

このグラフでは、スループットとしての測定が可能なサイズと時間のシンプルな比較パターンに増分バックアップとフルバックアップの両方が従っていることがわかります。アイドル状態のインスタンスでのバックアップ時間は、ベンチマーク環境でフルバックアップと増分バックアップのどちらを実行しているかに関係なく、平均 0.61 MB/s でほぼ一定です。

バックアップ遅延

バックアップ遅延パラメーターは、実稼働のワークロードに対するバックアップの影響の度合いを制限するために指定します。このパラメーターでは待機時間をミリ秒単位で指定します。指定した待機時間は、バックアップ操作においてファイル単位で適用されます。全体的な影響は、バックアップ対象のファイルのサイズにある程度左右されます。バックアップのパフォーマンスを MB/s 単位で測定すると、遅延がバックアップに及ぼす影響を合理的に比較できます。

• 通常のアプリケーションによる負荷が存在する状態でバックアップを実行すると、通常の負荷のスループットに悪影響があります。
• 影響はわずか（5 %程度）か、非常に大きく、75 %ものスループットの低下を引き起こす可能性があります。これは、アプリケーションによって何よりも大きく依存します。
• バックアップが CPU に高い負荷をかけることはありません。そのため、CPU 負荷が高い実稼働のワークロードは、I/O 負荷が高いワークロードよりもバックアップから受ける影響が少なくなります。

比較のため、スループットを取得する際は、ファイルシステムバックアップ（「tar」を使用）を使用して同じリポジトリファイルをバックアップしました。tar のパフォーマンスは同等ですが、遅延をゼロに設定したバックアップよりもわずかに高くなります。わずかな遅延を設定しただけでもバックアップのスループットが大幅に減少します。デフォルトの遅延である 10 ミリ秒を使用すると、スループットはさらに減少します。アプリケーションの全体的な使用率が非常に低いとき、またはアプリケーションが完全にアイドル状態のときにバックアップのスケジュールを設定できる場合は、バックアップをより迅速に続行できるように、遅延をデフォルト値よりも小さくするのが望ましいでしょう。

実行中のバックアップのアプリケーションのスループットが及ぼす実際の影響は、アプリケーションとインフラストラクチャの詳細に左右されます。遅延値の選択はアプリケーションの実証的分析に基づいておこなう必要がありますが、できる限り迅速にバックアップを完了するには、遅延値をできる限り小さくしてください。遅延値の選択とアプリケーションのスループットに及ぼす影響との相関関係は低いので、バックアップが及ぼす全体的な影響を最小限に抑えるには、遅延の選択時に全体的なバックアップ時間が短くなるようにします。完了までに 8 時間かかり、スループットに -20 ％の影響を及ぼすバックアップは、完了までに 2 時間かかり、スループットに -30 ％の影響を及ぼすバックアップよりも全体的な影響が大きくなる可能性があります。

参照

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