パフォーマンスの最適化 performance-optimization
Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。この値が達成可能で維持可能であることが判明したら、それを使用して、web サイトのパフォーマンスを監視し、潜在的な問題が発生しつつあるときにそれを示すことができます。
ターゲットオーディエンスの特性が異なることを反映して、オーサー環境とパブリッシュ環境では、目標とする応答時間が異なります。
オーサー環境 author-environment
この環境は、作成者がコンテンツを入力および更新する際に使用します。コンテンツページとそれらのページ上の個々の要素を更新する際に、パフォーマンスを集中的に消費する多数のリクエストを発生させる少数のユーザーに対応する必要があります。
パブリッシュ環境 publish-environment
この環境には、ユーザーに公開するコンテンツが置かれます。ここでは、リクエストの数がさらに多くなり、速度が極めて重要になります。しかし、リクエストの性質はそれほど動的ではないので、コンテンツのキャッシュやロードバランシングなどの付加的なパフォーマンス強化メカニズムを適用できます。
- パフォーマンス最適化のための設定が完了したら、Tough Day の手順に従って、高負荷の環境をテストしてください。
- パフォーマンスチューニングのヒントも参照してください。
パフォーマンスの最適化方法 performance-optimization-methodology
AEM プロジェクトのパフォーマンスを最適化する方法は、5 つの非常に単純なルールに要約されます。それらのルールを守れば、パフォーマンスの問題を未然に防ぐことができます。
これらのルールは web プロジェクト全般に当てはまり、プロジェクトマネージャーやシステム管理者にとっては、プロジェクトの立ち上げ時にパフォーマンスの問題に悩まされないようにするために有効です。
最適化の計画 planning-for-optimization
パフォーマンス最適化フェーズには、プロジェクト全体の作業のうち約 10%を予定します。実際のパフォーマンス最適化要件は、プロジェクトの複雑さのレベルと開発チームの経験によって異なります。プロジェクトによっては、そこまで時間を割く必要がなかったという結果になる可能性もありますが、パフォーマンス最適化には必ずこの程度の手間を見込んで計画を立てるのが実用的です。
プロジェクトの稼動開始当初は、可能な限り、少ないユーザーを対象として緩やかに運用を開始するのが望ましいと考えられます。そうすれば、全面的なサービス公開による過大なプレッシャーにさらされることなく、本番の経験を蓄積して最適化をいっそう進めることができるからです。
「本番」に入っても、パフォーマンスの最適化は終わりません。現在は、システムに「実際」の負荷が発生しています。開始後に追加の調整を計画することが重要です。
システムの負荷が変わり、システムのパフォーマンスプロファイルが時間の経過と共に変化するので、パフォーマンスの「調整」または「ヘルスチェック」は 6 か月~12 か月間隔でスケジュールする必要があります。
実際の状況に近いシミュレーション simulate-reality
Web サイトの運用を開始した後で、パフォーマンスの問題が判明した場合、負荷とパフォーマンスのテストで実際の状況に十分近いシミュレーションができていなかった可能性が高いです。
実際の状況に近いシミュレーションを行うことは難しく、「実際」の追求にどこまで手間をかけるかは、プロジェクトの性質によって判断します。「実際」とは、「実際のコード」や「実際のトラフィック」に限りません。「実際のコンテンツ」、特にコンテンツのサイズや構造が実際的であることも重要です。テンプレートの動作は、リポジトリのサイズと構造によって異なる場合があります。
適切な目標設定 establish-solid-goals
適切なパフォーマンス目標を設定することの重要性を軽視してはいけません。多くの場合、何らかのパフォーマンス目標に基づく活動を一旦開始すると、たとえその目標に確かな根拠がないとしても、後で軌道修正することは非常に困難です。
どうすれば適切で確実性の高いパフォーマンス目標を設定できるかというのは非常に難しい問題です。多くの場合、最も参考になるのは、類似性がある web サイト(例えば、新しい web サイトの前身となった web サイト)から実際のログとベンチマークを収集することです。
妥当性の維持 stay-relevant
ボトルネックの最適化は 1 つずつ適用していくことが重要です。ある対策の影響を検証しないうちに別の作業も並行して行うと、どの最適化対策が実際に効果を発揮したのかわからなくなります。
アジャイルな反復サイクル agile-iteration-cycles
パフォーマンスのチューニングは、目標を達成するまで測定、分析、最適化および検証のサイクルを続ける反復的なプロセスです。この点を考慮すると、サイクルを 1 周するごとに後で大がかりなテストプロセスを実施するよりも、最適化フェーズ内でアジャイルな検証プロセスを実施するほうがよいと考えられます。
これはつまり最適化作業を実施する開発者には、最適化目標が達成された場合にその事実をすぐ把握できる手段が必要だということです。目標に到達すれば最適化は終了するため、この情報は大きな価値があります。
基本的なパフォーマンスのガイドライン basic-performance-guidelines
一般的に、キャッシュされていない 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™プロファイラー。
デジタルアセットの読み込みと編集時のパフォーマンス performance-when-loading-and-editing-digital-assets
デジタルアセットの読み込みと編集には大量のデータが関与するので、パフォーマンスが問題になる場合があります。
この場合、次の 2 つの要素がパフォーマンスに影響します。
- CPU - 複数のコアがあると、トランスコーディングの際に処理がスムーズに行われます。
- ハードディスク - 並列の RAID ディスクを使用しても、同じ効果を得ることができます。
パフォーマンスを向上させるには、次の点を考慮します。
- 1 日にアップロードするアセットの数。次の式を基に概算できます。
- 編集を行う時間枠(通常は営業日の長さで、国際業務の場合はより長い時間が必要になります)。
- アップロードする画像の MB 単位の平均サイズ(および 1 つの画像につき生成されるレンディションのサイズ)。
- 平均データレートは次の式で算出されます。
- すべての編集の 80%が 20%の時間内に行われるため、ピーク時には平均のデータレートの 4 倍になります。このようなパフォーマンスを目標にします。
パフォーマンスの監視 performance-monitoring
パフォーマンス(またはパフォーマンスの不足)は、ユーザーが最初に認識する事柄の 1 つであるため、ユーザーインターフェイスを備えた他のアプリケーションと同様に、パフォーマンスは非常に重要です。AEM インストールのパフォーマンスを最適化するには、インスタンスの様々な属性とインスタンスの動作を監視する必要があります。
パフォーマンスの監視を実行する方法について詳しくは、パフォーマンスの監視を参照してください。
多くの場合、パフォーマンスの問題を引き起こす原因をトラックするのは、その影響が明白に確認できる状態であったとしても困難です。
まずは、正常に稼動しているシステムについて熟知しておく必要があります。適切に稼動する環境がどのように「見え」、「動作する」のかを把握していないと、パフォーマンスが低下したときに問題を特定するのが難しくなります。十分な時間をかけてスムーズに稼働しているシステムを調査し、パフォーマンス情報の収集が継続的なタスクであることを理解しておく必要があります。これにより、パフォーマンスが低下した場合に比較するための基準を設けることができます。
次の図は、AEM コンテンツの要求のパスおよびパフォーマンスに影響を及ぼす可能性のある様々な要素を示しています。
パフォーマンスは、ボリュームと処理能力のバランスでもあります。
- ボリューム - システムが処理および提供する出力の量です。
- 処理能力 - システムがボリュームを提供する能力です。
パフォーマンスは、web チェーン全体の様々な場所で示されます。
多くの場合、パフォーマンスに影響を与える機能領域がいくつかあります。
- キャッシュ
- アプリケーション(プロジェクト)コード
- 検索機能
パフォーマンスに関する基本ルール basic-rules-regarding-performance
パフォーマンスを最適化する際は、次の特定のルールに留意してください。
- パフォーマンスのチューニングを各プロジェクトでおこなう 。
- 開発サイクルの初期段階で最適化を行わない。
- パフォーマンスの良さは最も弱いリンクによって決まる。
- 常に処理能力とボリュームを比較して考える。
- 最初に重要な要素から最適化する。
- 必ず現実的な目標を設定してから最適化を実施する 。
パフォーマンスの設定 configuring-for-performance
パフォーマンスを最適化するために AEM(および基盤となるリポジトリ)の特定の要素を設定できます。設定可能な要素と推奨事項を次に示します。変更を行う前に、記載されている機能を使用するかどうか、またはどのように使用するかを確認しておく必要があります。
検索インデックスの作成 search-indexing
AEM 6.0 以降、Adobe Experience Manager は Oak ベースのリポジトリアーキテクチャを使用してします。
更新されたインデックス作成の情報については、次のページを参照してください。
ワークフローの同時処理 concurrent-workflow-processing
パフォーマンスを向上させるには、同時に実行するワークフロープロセス数を制限します。デフォルトでは、ワークフローエンジンで並行して処理できるワークフロー数は、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 を参照してください)。
これらのサービスを設定して、同時に実行するワークフロープロセスの最大数を制限します。
リポジトリでの設定 configuration-in-the-repo
sling:OsgiConfig ノードを使用してサービスを設定する場合は、既存のサービスの PID を探す必要があります。例:org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705Web コンソールを使用すると、PID を検出できます。
queue.maxparallel
という名前のプロパティを設定します。
Web コンソールでの設定 configuration-in-the-web-console
Web コンソールを使用してこれらのサービスを設定するには、Apache Sling Job Queue Configuration サービスファクトリで既存の設定項目を特定します。
Maximum Parallel Jobs という名前のプロパティを設定します。
特定のワークフロー用のキューの設定 configure-the-queue-for-a-specific-workflow
特定のワークフローモデルのジョブキューを作成して、そのワークフローモデルのジョブ処理を設定できるようにします。この方法では、設定が特定のワークフロー用の処理に影響を及ぼします。一方、デフォルトの 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 アセットの更新 ワークフローを使用して、ワークフロー用のジョブキューを作成します。
-
ジョブキューを作成する対象となるワークフローモデルを実行します。これにより、トピックの統計が生成されます。例えば、アセットに画像を追加して、DAM アセットの更新 ワークフローを実行します。
-
Sling ジョブコンソール(
https://<host>:<port>/system/console/slingevent
)をクリックします。 -
コンソールでワークフロー関連のトピックを確認します。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
-
これらのトピックごとに 1 つのジョブキューを作成します。ジョブキューを作成するには、Apache Sling Job Queue ファクトリサービス用のファクトリ設定を作成します。
このファクトリ設定は、Topics プロパティがワークフロージョブのトピックに一致する点を除き、ワークフローの同時処理で説明した Granite Workflow Queue と同様です。
AEM DAM アセット同期サービス cq-dam-asset-synchronization-service
AssetSynchronizationService
は、マウントされたリポジトリ(LiveLink、Documentum® など)からのアセットの同期に使用します。デフォルトでは、300 秒(5 分)ごとに定期チェックが行われるので、マウントされたリポジトリを使用しない場合は、このサービスを無効にすることができます。
この処理を行うには、OSGi サービスである CQ DAM Asset Synchronization Service を設定して、同期期間(scheduler.period
)を(最低)1 年(秒数で定義)にします。
複数の DAM インスタンス multiple-dam-instances
複数の DAM インスタンスをデプロイすると、パフォーマンスの強化に役立ちます。例えば、次のような場合です。
- オーサー環境用の多数のアセットの定期的なアップロードが原因で負荷が高い場合、別の専用の DAM インスタンスがオーサー環境にサービスを提供します。
- 世界各国(米国、ヨーロッパ、アジア)に複数のチームが存在します。
その他の考慮事項は次のとおりです。
- 作成者の「処理中の作業」と発行の「最終版」を分離する
- オーサーの内部ユーザーとパブリッシュの外部の訪問者/ユーザー(代理人、報道関係者、顧客、受講生など)を分離する。
品質保証のベストプラクティス best-practices-for-quality-assurance
パブリッシュ環境にとって、パフォーマンスは最も重要です。したがって、プロジェクトの実装時に、パブリッシュ環境に対して行うパフォーマンステストを慎重に計画し、分析する必要があります。
この節では、特に パブリッシュ 環境のパフォーマンステストのテストコンセプトを定義する際の問題を標準的な観点から概説します。この情報は、主に QA エンジニア、プロジェクトマネージャーおよびシステム管理者向けの内容となっています。
次に、パブリッシュ 環境での AEM アプリケーションのパフォーマンステストへの標準化されたアプローチを説明します。このパフォーマンステストには、次の 5 つの段階が含まれます。
制御は、すべてを包含する追加のプロセスであり、テストに必要ですが、それに限定されるものではありません。
知識の検証 verification-of-knowledge
最初の手順は、テストを開始する前に知っておく必要がある基本情報をドキュメント化することです。
- テスト環境のアーキテクチャ
- テストの必要な内部要素を詳細に示したアプリケーションマップ(単体で使用する場合と組み合わせて使用する場合の両方)
アーキテクチャのテスト test-architecture
パフォーマンステストに使用するテスト環境のアーキテクチャを文書化します。
計画した実稼働のパブリッシュ環境、Dispatcher およびロードバランサーを再現する必要があります。
アプリケーションマップ application-map
アプリケーション全体のマップを作成できる明確な概要を取得します(オーサー環境でのテストからこの情報を既に入手している可能性があります)。
アプリケーションの内部要素を図で表すことで、テスト要件の概要を示すことができます。色分けしたマップは、レポートのベースとしての役割も果たします。
範囲の定義 scope-definition
通常、アプリケーションには様々なユースケースがあります。重要なユースケースもあれば、それほど重要でないものもあります。
パブリッシュでのパフォーマンステストの範囲を絞り込むために、以下を定義することをお勧めします。
- 最も重要な業務上の事例
- 最も不可欠な技術上の事例
ユースケースの数は状況に応じて異なりますが、管理しやすい数(例えば 5~10)に制限する必要があります。
主要なユースケースを選択したら、測定に使用する重要業績評価指標(KPI)とツールをユースケースごとに定義できます。一般的な KPI の例を次に示します。
- エンドツーエンドの応答時間
- サーブレットの応答時間
- 単一のコンポーネントの応答時間
- サービスの応答時間
- スレスレッドプール内のアイドルスレッドの数
- 空き接続数
- CPU や I/O アクセスなどのシステムリソース
テスト方法 test-methodologies
この概念には、パフォーマンス目標の定義とテストに使用する 4 つのシナリオがあります。
- 単一コンポーネントテスト
- 組み合わせコンポーネントのテスト
- 運用開始 シナリオ
- エラーシナリオ
次の原則に基づきます。
コンポーネントのブレークポイント component-breakpoints
- 各コンポーネントには、パフォーマンスに関連する特定のブレークポイント(限界点)があります。つまり、特定のポイントに達するまではコンポーネントのパフォーマンスが良好で、そのポイントを超えるとパフォーマンスが急激に低下します。
- アプリケーションの概要をすべて把握するには、最初にコンポーネントを検証して、それぞれのブレークポイントを確認しておく必要があります。
- ブレークポイントを検出するために、負荷テストを実施できます。このテストでは、ある特定の期間にわたってユーザー数を増やして負荷を上げていきます。この負荷およびコンポーネントの応答を監視することにより、コンポーネントのブレークポイントに達したときの特定のパフォーマンスの動作を確認できます。このポイントは、1 秒あたりの同時トランザクションの数と同時ユーザーの数によって限定できます(コンポーネントがこの KPI の影響を受ける場合)。
- この情報は、改善のためのベンチマークとして機能し、使用される測定の効率を示し、テストシナリオの定義に役立ちます。
トランザクション transactions
- トランザクションという用語は、ページ自体と後続のすべての呼び出しを含む、完全な web ページのリクエストを表すために使用されます。つまり、ページリクエスト、AJAX 呼び出し、画像およびその他のオブジェクト リクエストドリルダウン などです。
- 各リクエストを完全に分析するには、コールスタックの各要素を表現してから、それぞれの平均処理時間の合計を求めることができます。
パフォーマンス目標の定義 defining-the-performance-goals
範囲と関連 KPI を定義したら、特定のパフォーマンス目標を設定します。このプロセスでは、テストシナリオとターゲット値の策定が必要になります。
平均条件下とピーク条件下の両方でパフォーマンスをテストします。さらに、運用開始シナリオのテストを実施して、初公開時の web サイトに対する関心の増加に対応できることを確認する必要があります。
既存の web サイトから収集した任意のエクスペリエンスや統計情報も、今後の目標の決定に役立ちます。例えば、ライブ web サイトで最も多いトラフィックです。
単一コンポーネントテスト single-component-tests
極めて重要なコンポーネントは、平均条件下とピーク条件下の両方でテストする必要があります。
どちらの場合も、定義済みの数のユーザーがシステムを使用する際の 1 秒あたりのトランザクションの予想数を定義できます。
組み合わせコンポーネントのテスト combined-component-tests
組み合わせてコンポーネントをテストすると、アプリケーションの動作がより詳細に反映されます。再び平均時とピーク時の条件でテストする必要があります。
運用開始のテスト going-live-tests
Web サイトが公開されてからの最初の数日間は、より高い関心レベルを期待できます。このシナリオは、テストするピーク時の値よりも大きくなります。アドビでは、運用開始のシナリオをテストして、システムがこの状況に対応できることを確認することをお勧めします。
エラーシナリオテスト error-scenario-tests
エラーシナリオをテストし、システムが正しく適切に対応していることを確認します。エラー自体の処理方法だけでなく、エラーがパフォーマンスに与える影響についても説明します。次に例を示します。
- ユーザーが検索ボックスに検索用語を入力しようとするとどうなるか
- 検索用語が一般的すぎて、返される結果の数が非常に多い場合はどうなるか
このようなテストの策定時には、すべてのシナリオが定期的に発生するわけではない点に注意してください。ただし、テストがシステム全体に及ぼす影響は重要です。
耐久テスト endurance-tests
システムを継続的な期間(数時間または数日)実行した後にのみ発生する問題があります。耐久テストは、必要とされるある一定の期間にわたる、継続的な平均負荷を確認するために使用します。その後、パフォーマンスの低下を分析できます。
最適化 optimization
実装の後半の段階では、アプリケーションを最適化して、パフォーマンスの目標を達成または最大化します。
実施した最適化をすべてテストして、次の点を確認してください。
- 機能に影響を及ぼさない
- リリース前に負荷テストを実施して検証済みである
負荷の生成、パフォーマンスの監視および結果の分析に役立つ様々なツールが用意されています。これらのツールの一部を次に示します。
最適化後、再度テストして影響を確認します。
レポート reporting
継続的なレポートにより、すべてのユーザーが状況を把握できます。前述のように、色分けでアーキテクチャマップをこの状態に使用できます。
すべてのテストが完了したら、次の情報を報告します。
- 発生した重大なエラー
- 重大ではない問題(詳細な調査は必要)
- テスト中の想定事項
- テストから得られたレコメンデーション
Dispatcher の使用時のパフォーマンスの最適化 optimizing-performance-when-using-the-dispatcher
Dispatcherはアドビのキャッシュ/ロードバランシングツールです。Dispatcher を使用する場合は、キャッシュパフォーマンスを確保するために web サイトの最適化を検討してください。
Dispatcher には、web サイトで活用するとパフォーマンスが最適化される、複数の組み込みのメカニズムが用意されています。この節では、キャッシュのメリットを最大化するように web サイトをデザインする方法について説明します。
Dispatcher のキャッシュ率の計算 calculating-the-dispatcher-cache-ratio
キャッシュ率の計算式では、システムが受け取ったリクエスト総数のうちキャッシュによって処理されたリクエストの割合が概算されます。キャッシュ率を計算するには、次の情報が必要です。
-
要求の総数。この情報は、Apache の
access.log
で確認できます。詳しくは、公式の Apache ドキュメントを参照してください。 -
パブリッシュインスタンスが提供したリクエスト数。この情報は、インスタンスの
request.log
で確認できます。詳しくは、request.log の解釈およびログファイルの検索を参照してください。
キャッシュ率の計算式は次のとおりです。
- 要求の総数から公開における要求の数を 差し引き、それを要求の総数で 割ります。
例えば、リクエスト総数が 129,491 であり、パブリッシュインスタンスによって処理されたリクエスト数が 58,959 である場合、キャッシュ率は (129,491 - 58,959)/129,491 = 54.5% です。
パブリッシャーと Dispatcher が 1 対 1 のペアでない場合、正確な測定値を得るには、すべての Dispatcher とパブリッシャーからのリクエストを加算します。詳しくは、推奨されるデプロイメントも参照してください。
一貫したページエンコーディングの使用 using-consistent-page-encoding
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。Dispatcher で応答ヘッダーをキャッシュしない場合、ページエンコーディング情報をヘッダーに格納すると、問題が生じる可能性があります。この場合、Dispatcher がキャッシュからページを提供すると、ページで web サーバーのデフォルトのエンコーディングが使用されます。この問題を回避する方法は 2 つあります。
- 1 つのエンコーディングのみを使用する場合は、web サーバーで使用されるエンコーディングが、AEM web サイトのデフォルトのエンコーディングと同じであることを確認します。
- エンコーディングを設定するには、次の例のように、
<META>
タグを HTMLhead
セクションに使用します。
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
URL パラメーターの使用回避 avoid-url-parameters
可能な限り、キャッシュするページの URL パラメーターは使用しないでください。例えば、ピクチャーギャラリーがある場合、次の URL はキャッシュされません(Dispatcher が 適切に設定されている場合を除く)。
www.myCompany.com/pictures/gallery.html?event=christmas&page=1
ただし、次のように、これらのパラメーターをページ URL に配置できます。
www.myCompany.com/pictures/gallery.christmas.1.html
gallery.html
と同じページおよび同じテンプレートを呼び出します。テンプレートの定義では、ページをレンダリングするスクリプトを指定できます。または、すべてのページに同じスクリプトを使用できます。URL でカスタマイズ customize-by-url
ユーザーがフォントサイズ(またはその他のレイアウトのカスタマイズ)を変更できるようにする場合は、様々なカスタマイズが URL に反映されていることを確認します。
例えば、Cookie はキャッシュされないので、フォントサイズを Cookie(または同様のメカニズム)に格納した場合、キャッシュされたページのフォントサイズは保持されません。その結果、Dispatcher は任意のフォントサイズのドキュメントをランダムに返します。
URL にフォントサイズをセレクターとして含めると、次の問題を回避できます。
www.myCompany.com/news/main.large.html
www.myCompany.com/news/main.print.html
タイトルとして使用されている画像ファイルの無効化 invalidating-image-files-used-as-titles
ページのタイトルや他のテキストを画像としてレンダリングする場合は、ページ上のコンテンツの更新時にファイルが削除されるように、ファイルを保存することをお勧めします。
-
画像ファイルを、ページと同じフォルダーに配置します。
-
画像ファイルに次の命名形式を使用します。
<page file name>.<image file name>
例えば、file myPage.title.gif
にページ のタイトル myPage.html
を格納できます。ページが更新されると、このファイルは自動的に削除されるので、ページタイトルに対する変更はキャッシュに自動的に反映されます。
ナビゲーションに使用された画像ファイルの無効化 invalidating-image-files-used-for-navigation
ナビゲーションエントリに画像を使用する場合、この方法はタイトルと同じですが、少し複雑です。すべてのナビゲーション画像をターゲットページと共に保存します。通常とアクティブ用に 2 つの画像を使用する場合は、次のスクリプトを使用できます。
- 通常どおりページを表示するスクリプト。
- 「.normal」リクエストを処理し、通常の画像を返すスクリプト。
- 「.active」リクエストを処理し、アクティベートされた画像を返すスクリプト。
コンテンツの更新でこれらの画像とページが確実に削除されるように、ページと同じ名前のハンドルでこれらの画像を作成することが重要です。
変更されていないページの場合、画像はキャッシュに残りますが、ページ自体は自動的に無効化されます。
パーソナライズ機能 personalization
パーソナライズ機能は必要な場所に制限することをお勧めします。その理由を次に示します。
- 自由にカスタマイズ可能な開始ページを使用する場合は、ユーザーが要求するたびにそのページを構成する必要があります。
- これに対して、10 個の異なる開始ページを選択できるようにする場合は、各ページをキャッシュして、パフォーマンスを向上させることができます。
(例えば)ユーザーの名前をタイトルバーに入れて各ページをパーソナライズすると、パフォーマンスに影響を与えます。
1 つのページに制限付きコンテンツと公開コンテンツを混在させる場合、Dispatcher のサーバーサイドインクルードを利用する方法や、ブラウザーの Ajax 経由でクライアントサイドインクルードを利用する方法を検討します。
スティッキー接続 sticky-connections
スティッキー接続を使用すると、1 人のユーザー用のドキュメントがすべて同じサーバーで作成されるようになります。ユーザーがそのフォルダーを離れて後から戻ってきた場合も、この接続は維持されます。Web サイトのスティッキー接続に必要なすべてのドキュメントを保持するには、フォルダーを 1 つ定義します。他のドキュメントを中に含めないようにしてください。このシナリオでは、パーソナライズされたページとセッションデータを使用する場合に、ロードバランシングに影響が生じます。
MIME タイプ mime-types
ブラウザーがファイルのタイプを判別する方法は 2 とおりあります。
- 拡張子(例:
.html
、.gif
および.jpg
)。 - サーバーがファイルと共に送信する MIME タイプ。
ほとんどのファイルでは、MIME タイプがファイル拡張子で暗黙に指定されます。つまり
- 拡張子(例:
.html
、.gif
および.jpg
)。 - サーバーがファイルと共に送信する MIME タイプ。
ファイル名に拡張子がない場合は、プレーンテキストとして表示されます。
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。Dispatcher で応答ヘッダーをキャッシュしない場合、MIME タイプは HTTP ヘッダーの一部になります。つまり、AEM アプリケーションから返されるファイルが、認識されたファイル拡張子を持たず、代わりに MIME タイプに依存する場合は、ファイルが正しく表示されない可能性があります。
ファイルが適切にキャッシュされるようにするには、次のガイドラインに従います。
- ファイルの拡張子が常に適切であることを確認します。
download.jsp?file=2214
のような URL を持つ汎用のファイル提供スクリプトは避けます。ファイル仕様を含んだ URL を使用するには、スクリプトを書き換えます。前の例では、この書き換えはdownload.2214.pdf
となります。
バックアップのパフォーマンス backup-performance
この節では、AEMのバックアップのパフォーマンスと、バックアップアクティビティがアプリケーションのパフォーマンスに与える影響を評価するために使用される一連のベンチマークについて説明します。AEM のバックアップは、実行中にシステムに大きな負荷を与えます。アドビでは、この影響と、これらの影響を調整しようとするバックアップ遅延設定の効果を測定します。目的は、現実的な構成でのバックアップの期待されるパフォーマンスと実稼働データの量に関する参照データを提供し、計画されたシステムのバックアップ時間を見積もる方法に関するガイダンスを提供することです。
参照環境 reference-environment
物理システム physical-system
このドキュメントで報告された結果は、次の設定を使用した参照環境で実行されたベンチマークから取得されました。この設定は、データセンターの典型的な実稼働環境と似ています。
- HP ProLiant DL380 G6, 8 CPUs x 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 アレイ上のローカルディスクストレージに単一の大きなディスクボリュームを物理的に配置するように設定されます。
AEM の設定では、リポジトリとデータストアが、オペレーティングシステムと AEM ソフトウェアと共に、同じ論理ボリュームに配置されます。バックアップのターゲットディレクトリも、この論理ファイルシステム上に存在します。
データ量 data-volumes
バックアップベンチマークで使用されるデータボリュームのサイズを次の表に示します。初期のベースラインコンテンツが最初にインストールされた後で、バックアップ対象のコンテンツのサイズを増やすために既知量のデータが追加されます。コンテンツの大幅な増加と 1 日に生成されるコンテンツを表すために、バックアップは特定の増分で作成されます。コンテンツ(ページ、画像、タグ)の配布は、現実的な実稼働アセット構成に概ね基づいています。ページ、画像およびタグは最大 800 の子ページに制限されます。各ページには、タイトル、Flash、テキスト/画像、ビデオ、スライドショー、フォーム、テーブル、クラウドおよびカルーセルコンポーネントが含まれます。画像は、400 個の固有のファイル(サイズは 37 ~ 594 KB)のプールからアップロードされます。
バックアップのベンチマークは、それぞれにコンテンツセットを追加して繰り返されます。
ベンチマークのシナリオ benchmark-scenarios
バックアップのベンチマークは 2 つの主要なシナリオに対応しています。1 つはシステムでアプリケーションによる負荷が大きい場合のバックアップで、もう 1 つはシステムがアイドル状態の場合のバックアップです。一般的なレコメンデーションは、できるだけ AEM がアイドル状態の場合にバックアップを実行することですが、システムに負荷がかかっている際にバックアップを実行しなければならない場合もあります。
- アイドル状態 - バックアップは、AEM 上の他のアクティビティを使用せずに実行されます。
- 負荷下 - オンラインプロセスから 80 %の負荷がシステムにかかっている状態でバックアップが実行されます。負荷に対する影響を確認するためにバックアップ遅延を変更しました。
バックアップ時間と生成されるバックアップのサイズは AEM サーバーのログから取得します。通常は、AEM がアイドル状態であるオフタイム(深夜など)にバックアップのスケジュールを設定することをお勧めします。このシナリオは、推奨されるアプローチを表しています。
負荷を構成するのは、作成されたページ、削除されたページ、移動およびクエリで、負荷の大部分はページの移動とクエリによるものです。大量のページを追加および削除することでワークスペースのサイズが継続的に増加し、バックアップを完了できなくなります。スクリプトが使用する負荷の分散により、75%がページの移動、24%がクエリ、1%がページの作成に割り当てられます(ネストされたサブページのない単一のレベル)。アイドル状態のシステムでピーク時の 1 秒あたりの平均トランザクション数を実現するには 4 つの同時スレッドを使用します。これは、負荷状態でのバックアップのテスト時に使用されます。
バックアップのパフォーマンスに負荷が及ぼす影響は、このアプリケーションによる負荷がある状態とない状態のパフォーマンスの差で推測できます。アプリケーションのスループットにバックアップが及ぼす影響は、同時バックアップを実行している状態と実行していない状態でのこのシナリオのトランザクションのスループット(1 時間あたり)と、異なる「バックアップ遅延」設定を使用してバックアップを実行している状態でのトランザクションのスループット(1 時間あたり)を比較して特定されます。
- 遅延設定 - いくつかのシナリオでは、バックアップ遅延設定も変更しました。10 ミリ秒(デフォルト)、1 ミリ秒、0 ミリ秒の値を使用して、この設定がバックアップのパフォーマンスに及ぼす影響を確認しました。
- バックアップの種類 - すべてのバックアップは、tar コマンドが直接使用された場合の比較の場合を除き、zip を作成せずに、バックアップディレクトリに対して行われたリポジトリの外部バックアップでした。増分バックアップを zip ファイルに作成できないので、また、以前の完全バックアップが zip ファイルの場合は、バックアップディレクトリ方式が本番環境で最も頻繁に使用されます。
結果のまとめ summary-of-results
バックアップ時間とスループット backup-time-and-throughput
これらのベンチマークの主な結果から、バックアップの種類と全体的なデータ量の関数としてバックアップ時間がどのように変化するかを示すことができます。次のチャートは、デフォルトのバックアップ設定を使用して取得したバックアップ時間を、合計ページ数の関数として示しています。
アイドル状態のインスタンスでのバックアップ時間は、フルバックアップか増分バックアップかに関係なく平均 0.608 MB/s でほぼ一定です(下のチャート参照)。バックアップ時間は単にバックアップされるデータ量の関数です。フルバックアップの完了に要する時間は、合計ページ数が増加すると明らかに長くなります。増分バックアップの完了に要する時間も合計ページ数が増加すると長くなりますが、はるかに低い割合です。増分バックアップの完了に要する時間が短いのは、バックアップ対象のデータが比較的少量であるためです。
生成されるバックアップのサイズは、バックアップの完了に要する時間の主要な決定要因です。次のチャートは、最終的なバックアップサイズの関数としてバックアップの所要時間を示しています。
このチャートでは、スループットとしての測定が可能なサイズと時間のシンプルな比較パターンに増分バックアップとフルバックアップの両方が従っていることがわかります。アイドル状態のインスタンスのバックアップ時間は、ベンチマーク環境でのフルバックアップまたは増分バックアップに関係なく、1 秒あたり平均 0.61 MBでほぼ一定です。
バックアップ遅延 backup-delay
バックアップ遅延パラメーターは、実稼働のワークロードに対するバックアップの影響の度合いを制限するために指定します。このパラメーターでは待機時間をミリ秒単位で指定します。指定した待機時間は、バックアップ操作においてファイル単位で適用されます。全体的な影響は、バックアップ対象のファイルのサイズによってある程度左右されます。バックアップのパフォーマンスを MB/s 単位で測定すると、遅延がバックアップに及ぼす影響を合理的に比較できます。
- 通常のアプリケーションの負荷と同時にバックアップを実行すると、通常の負荷のスループットに悪影響を与えます。
- 影響がわずかな(5%ほど)場合もあれば、75%ものスループットの低下させる非常に大きな影響を受ける場合もあります。多くの場合、アプリケーションによって異なります。
- バックアップが CPU に高い負荷をかけることはありません。そのため、CPU 負荷が高い実稼働のワークロードは、I/O 負荷が高いワークロードよりもバックアップから受ける影響が少なくなります。
比較のため、スループットを取得する際、ファイルシステムバックアップ(「tar」)を使用して同じリポジトリファイルをバックアップしました。tar のパフォーマンスは同等ですが、遅延をゼロに設定したバックアップよりもわずかに高くなります。わずかな遅延を設定しただけでもバックアップのスループットが大幅に減少します。デフォルトの遅延である 10 ミリ秒を使用すると、スループットはさらに減少します。アプリケーションの全体的な使用率が低い場合や、またはアプリケーションがアイドル状態の場合にバックアップをスケジュールする場合は、デフォルト値よりも小さくして遅延を減らし、バックアップをより迅速に実行します。
実行中のバックアップのアプリケーションのスループットが及ぼす実際の影響は、アプリケーションとインフラストラクチャの詳細に左右されます。遅延値の選択は、アプリケーションの実証的分析に基づいて行う必要がありますが、できる限り迅速にバックアップを完了するには、遅延値をできる限り小さくする必要があります。遅延値の選択とアプリケーションのスループットに及ぼす影響との相関関係は低いので、遅延を選択する際に全体的なバックアップ時間を短くすることで、バックアップ全体の影響を最小限に抑える必要があります。完了までに 8 時間かかり、スループットに -20%の影響を及ぼすバックアップは、完了までに 2 時間かかり、スループットに -30%の影響を及ぼすバックアップよりも全体的な影響が大きくなる可能性があります。