パフォーマンスに関する一般的なガイドラインについては、パフォーマンスガイドラインのページを参照してください。
パフォーマンスに関する問題のトラブルシューティングと修正について詳しくは、パフォーマンスツリーも参照してください。
さらに、パフォーマンスチューニングのヒントに関するナレッジベースの記事を参照することもできます。
Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。当然、応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。達成可能かつ維持可能な値を定義したことを確認したうえで、その値に基づいて Web サイトのパフォーマンスを監視すると、潜在的な問題が発生しつつあるときに、その状況を検知することができます。
オーサー環境とパブリッシュ環境では、対象となる利用者の特性が異なるので、目指す応答時間が異なります。
この環境は、コンテンツを入力および更新する作成者によって使用されます。そのため、少人数のユーザー向けに構築されている必要があります。各ユーザーは、コンテンツページとそのページ上の個々の要素を更新するときに、パフォーマンスに重点を置いた多数の要求を生成します。
この環境には、ユーザー向けに提供するコンテンツが置かれます。したがって要求数は非常に多く、速度が非常に重要となります。ただし、それらの要求の性質はさほど動的な内容ではないので、コンテンツのキャッシュや負荷分散などの付加的なパフォーマンス強化メカニズムを適用できます。
AEM プロジェクトのパフォーマンスを最適化する方法は、5 つの非常に単純なルールに要約されます。それらのルールを守れば、パフォーマンスの問題が発生するのを最初から防ぐことができます。
各ルールの内容は一般的な web プロジェクトすべてに当てはまる部分が多く、プロジェクトマネージャーやシステム管理者にとっては、プロジェクトの稼動開始時にパフォーマンスの問題に悩まされないようにするために有効です。
パフォーマンスの最適化フェーズには、プロジェクト全体の作業のうち 10 %程度を割くことが望ましいと考えられます。もちろん、パフォーマンスの最適化に必要な作業の量は、プロジェクトの複雑さや開発チームの経験によって異なります。プロジェクトによっては、そこまで時間を割く必要がなかったという結果になる可能性もありますが、パフォーマンスの最適化には必ずこの程度の手間を見込んで計画を立てるのが実用的です。
プロジェクトの稼動開始当初は、可能な限り、少ないユーザーを対象として緩やかに運用を開始するのが望ましいと考えられます。そうすれば、全面的なサービス公開による過大なプレッシャーにさらされることなく、本番の経験を蓄積して最適化をいっそう進めることができるからです。
システムが本番に入っても、パフォーマンスの最適化は終わりません。むしろ、サービスを開始して「現実の」システム負荷が判明した後にこそ、再調整をおこなうように計画を立てておくことが重要です。
時が経つにつれて、システム負荷は変化し、システムのパフォーマンスプロファイルは遷移していきます。6 ~ 12 ヶ月おきにパフォーマンスの「チューンアップ」または「ヘルスチェック」を続けていくようにしてください。
Web サイトの運用を開始した後で、パフォーマンスの問題が発生することが判明した場合、理由は 1 つしかありません。それは、負荷とパフォーマンスのテストで実際の状況に十分近いシミュレーションができていなかったということです。
実際の状況に近いシミュレーションを行うのは難しいことであり、「実際」の追求にどこまで手間をかけるかは、プロジェクトの性質に応じて無理のない範囲で判断する必要があります。「実際」とは、「実際のコード」や「実際のトラフィック」に限りません。「実際のコンテンツ」、特にコンテンツのサイズや構造が実際的であることも重要です。リポジトリのサイズや構造が変われば、テンプレートの挙動はまったく違ってくる可能性があるということを常に意識してください。
適切なパフォーマンス目標を設定することの重要性を軽視してはいけません。何らかのパフォーマンス目標に基づく活動を一旦開始すると、たとえその目標に確かな根拠がないとしても、後で軌道修正することは非常に困難です。
どうすれば適切で確実性の高いパフォーマンス目標を設定できるかというのは非常に難しい問題です。多くの場合、最も参考になるのは、類似性がある Web サイト(例えば、前身となったサイト)で採取した実際のログやベンチマーク結果の情報です。
ボトルネックの最適化は 1 つずつ適用していくことが重要です。ある対策の影響を検証しないうちに別の作業も並行しておこなうと、どの最適化対策が実際に効果を発揮したのかわからなくなります。
パフォーマンスのチューニングは、目標を達成するまで測定、分析、最適化および検証のサイクルを続ける反復的なプロセスです。この性質を考えると、サイクルを 1 周するごとに後で大がかりなテストプロセスを実施するよりも、最適化フェーズ内でアジャイルな検証プロセスを実施するほうがよいと考えられます。
これはつまり、最適化作業を実施する開発者には、最適化目標が達成された場合にその事実をすぐ把握できる手段が必要だということです。目標の達成は最適化作業の終了を意味するだけに、いつ達成されたかという情報には大きな価値があります。
大まかな目安として、キャッシュされていない HTML 要求の応答時間は 100 ms 未満に抑えます。より具体的には次のようなガイドラインに従うとよいでしょう。
以上の数値は、次の条件を前提としています。
パフォーマンスに影響しやすい要因はいくつかありますが、それらは主に次に関連する問題です。
JVM および OS レベルの調整は、通常、大幅なパフォーマンス向上には結び付かないので、最適化サイクルの最後に実行すれば十分です。
コンテンツリポジトリの構造化の方法はパフォーマンスにも影響を及ぼす可能性があります。最適なパフォーマンスを確保するために、コンテンツリポジトリ内の個々のノードに接続される子ノードの数は、通常 1,000 個未満にする必要があります。
通常のパフォーマンス最適化では、次の要素を使用します。
request.log
デジタルアセットの読み込み時と編集時には大量のデータが関係してくるので、パフォーマンスが問題になります。
この場合、パフォーマンスに影響を及ぼす要素は次の 2 つです。
パフォーマンスを向上するには、次の点を考慮します。
パフォーマンス(またはパフォーマンスの欠如)はユーザーが最初に認識する点の 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 サービスファクトリから次のジョブキューサービスが作成されています。
これらのサービスを設定して、同時に実行するワークフロープロセスの最大数を制限します。
特定のワークフローモデル用のジョブキューを作成していない限り、このようなジョブキューの設定はすべてのワークフローに影響を及ぼします(特定のワークフロー用のキューの設定を参照)。
sling:OsgiConfig ノードを使用してサービスを設定する場合は、既存のサービスの PID(例:org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705)を特定する必要があります。Web コンソールを使用すると、PID を検出できます。
queue.maxparallel
という名前のプロパティを設定する必要があります。
Web コンソールを使用してこれらのサービスを設定するには、Apache Sling Job Queue Configuration サービスファクトリで既存の設定項目を特定します。
並列ジョブの最大数という名前のプロパティを設定する必要があります。
特定のワークフローモデル用のジョブキューを作成して、そのワークフローモデル用のジョブの処理を設定できるようにします。この方法では、設定が特定のワークフロー用の処理に影響を及ぼします。一方、デフォルトの 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 と同様です。
AssetSynchronizationService
は、マウントされたリポジトリ(LiveLink、Documentum など)からのアセットの同期に使用します。デフォルトでは、300 秒(5 分)ごとに定期チェックが行われるので、マウントされたリポジトリを使用しない場合は、このサービスを無効にすることができます。
この処理を行うには、OSGi サービスである CQ DAM Asset Synchronization Service を設定して、同期期間(scheduler.period
)を(最低)1 年(秒数で定義)にします。
複数の DAM インスタンスをデプロイすると、パフォーマンスの強化に役立ちます。例えば、次のような場合です。
その他の考慮事項は次のとおりです。
パブリッシュ環境にとって最も重要なのはパフォーマンスです。そのため、プロジェクトの実装時にパブリッシュ環境に対しておこなうパフォーマンステストについて注意深く計画および分析する必要があります。
ここでは、パブリッシュ環境におけるパフォーマンステストに特化したテスト概念の定義に関連する問題の標準化された概要を示します。これは主に QA エンジニア、プロジェクトマネージャーおよびシステム管理者に役立つ情報です。
次に、公開環境での AEM アプリケーションのパフォーマンステストへの標準化されたアプローチを説明します。これには、次の 5 つのフェーズが含まれます。
包括的な追加のプロセスとして「制御」があります。これは必要なプロセスですが、テストに限定されるものではありません。
最初の手順は、テストの開始前に知っておく必要のある基本情報の文書化です。
パフォーマンステストに使用するテスト環境のアーキテクチャを明確に文書化してください。
計画した実稼働のパブリッシュ環境、Dispatcher およびロードバランサーを再現する必要があります。
概要を明確にするために、アプリケーション全体のマップを作成できます(オーサー環境におけるテストからこの情報を入手できる可能性があります)。
アプリケーションの内部要素を図で表すことで、テスト要件の概要を説明できます。色分けしたマップは、レポートの基盤としての役割も果たします。
通常、アプリケーションは様々な使用事例に対応しています。これらの事例は非常に重要なものと、それほど重要でないものに分けられます。
公開におけるパフォーマンステストの範囲を絞り込むために、次の項目を定義することをお勧めします。
事例の数は状況に応じて異なりますが、管理しやすい数(例えば、5 ~ 10)に制限してください。
主要な事例を選択したら、測定に使用する重要業績評価指標(KPI)とツールを事例ごとに定義できます。一般的な KPI の例を次に示します。
この概念には、パフォーマンスの目標の定義およびテストに使用する 4 つのシナリオがあります。
基盤となる原則は次のとおりです。
範囲と関連する KPI の定義が完了したら、パフォーマンスの目標を設定できます。この作業には、テストシナリオおよびターゲットとなる値の策定が含まれます。
平均時とピーク時の両方の条件下でパフォーマンスをテストしてください。また、運用開始のシナリオのテストを実施して、運用開始時の Web サイトに対する関心の増加に対応できるようにする必要があります。
既存の Web サイトから収集したエクスペリエンス(統計)も将来の目標を決める際に役立ちます。例えば、本番の Web サイトからの上位のトラフィックなどです。
平均時とピーク時の両方の条件下で、不可欠なコンポーネントをテストする必要があります。
どちらの場合も、定義済みの数のユーザーがシステムを使用する際の 1 秒あたりのトランザクションの予想数を定義できます。
コンポーネント | テストの種類 | いいえ。/ユーザー | トランザクション数/秒(予想) | トランザクション数/秒(テスト済み) | 説明 |
---|---|---|---|---|---|
ホームページ:1 ユーザー | 平均 | 1 | 1 | ||
ピーク時 | 1 | 3 | |||
ホームページ:100 ユーザー | 平均 | 100 | 3 | ||
ピーク時 | 100 | 3 |
組み合わされたコンポーネントをテストすると、アプリケーションの動作がより忠実に反映されます。この場合も、平均時とピーク時の両方の条件下でテストを実施する必要があります。
シナリオ | コンポーネント | いいえ。/ユーザー | トランザクション数/秒(予想) | トランザクション数/秒(テスト済み) | 説明 |
---|---|---|---|---|---|
混在:平均時 | ホームページ | 10 | 1 | ||
検索 | 10 | 1 | |||
ニュース | 10 | 2 | |||
イベント | 10 | 1 | |||
アクティベート | 10 | 3 | オーサーの動作のシミュレーション | ||
混在:ピーク時 | ホームページ | 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 | 3 | オーサーの動作のシミュレーション |
実装の後半の段階では、アプリケーションを最適化して、パフォーマンスの目標を達成または最大化する必要があります。
実施した最適化をすべてテストして、次の点を確認してください。
負荷の生成、パフォーマンスの監視および結果の分析に役立つ様々なツールが用意されています。
最適化の後にもう一度テストを実施して、影響を確認する必要があります。
すべてのユーザーが常にステータスを把握できるようにするために、継続的にレポートを作成する必要があります。前述のとおり、色分けしたアーキテクチャマップをこの目的で使用できます。
すべてのテストが完了すると、次の項目についてレポートできます。
Dispatcher は Adobe のキャッシュ/ロードバランシングツールです。Dispatcher を使用する場合は、キャッシュパフォーマンスを確保するために web サイトの最適化を検討する必要があります。
Dispatcher のバージョンは AEM とは無関係ですが、Dispatcher のドキュメントは AEM のドキュメントに組み込まれています。最新バージョンの AEM のドキュメントに組み込まれている Dispatcher のドキュメントを必ず使用してください。
以前のバージョンの AEM のドキュメントに組み込まれている Dispatcher のドキュメントへのリンクをたどると、このページにリダイレクトされる可能性があります。
Dispatcher には、Web サイトで活用するとパフォーマンスが最適化される、複数の組み込みのメカニズムが用意されています。ここでは、キャッシュのメリットを最大化するように Web サイトをデザインする方法について説明します。
まず覚えておいてほしいのは、Dispatcher は標準の Web サーバーにキャッシュを格納するという点です。これは、次のことを意味します。
通常、多くのキャッシュ戦略は適切な URL の選択を含んでおり、この追加データには依存しないことです。
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュすることもできます。HTTP 応答ヘッダーのキャッシュを参照してください。
キャッシュ率の計算式では、システムが受け取った要求の総数のうちキャッシュによって処理された要求の割合(%)が概算されます。キャッシュ率を計算するには、次の情報が必要です。
要求の総数。この情報は、Apache の access.log
で確認できます。詳しくは、Apache の公式ドキュメントを参照してください。
パブリッシュインスタンスが処理した要求の数。この情報は、インスタンスの request.log
で確認できます。詳しくは、request.log の解釈およびログファイルの検索を参照してください。
キャッシュ率の計算式は次のとおりです。
例えば、要求の総数が 129,491 であり、パブリッシュインスタンスによって処理された要求の数が 58,959 である場合、キャッシュ率は (129,491 - 58,959)/129,491 = 54.5%です。
パブリッシャーと Dispatcher が 1 対 1 のペアではない場合、正確な測定値を得るには、すべての Dispatcher とパブリッシャーからの要求を加算する必要があります。推奨されるデプロイメントも参照してください。
最適なパフォーマンスを確保するには、90%から 95%のキャッシュ率をお勧めします。
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。Dispatcher で応答ヘッダーをキャッシュしない場合、ページエンコーディング情報をヘッダーに格納すると、問題が生じる可能性があります。この場合、Dispatcher がキャッシュからページを提供すると、Web サーバーのデフォルトのエンコーディングがそのページに使用されます。この問題を回避する方法は 2 つあります。
<META>
タグを HTML の head
セクションで使用して、エンコーディングを設定します。次に例を示します。 <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
可能な限り、キャッシュするページには URL パラメーターを使用しないでください。例えば、サイトに写真ギャラリーがあるとします。このとき、次の URL はキャッシュされません(Dispatcher が適切に設定されている場合を除く)。
www.myCompany.com/pictures/gallery.html?event=christmas&page=1
しかし、次のようにして、これらのパラメーターをページ URL に追加することができます。
www.myCompany.com/pictures/gallery.christmas.1.html
この URL は、gallery.html
と同じページおよび同じテンプレートを呼び出します。テンプレートの定義では、ページをレンダリングするスクリプトを指定できます。または、すべてのページに同じスクリプトを使用できます。
ユーザーによるフォントサイズの変更(またはその他の任意のレイアウトのカスタマイズ)を許可する場合は、それぞれのカスタマイズが URL に反映されるようにする必要があります。
例えば、cookie はキャッシュされないので、フォントサイズを cookie(または同様のメカニズム)に格納した場合、キャッシュされたページではフォントサイズが維持されません。その結果、Dispatcher は任意のフォントサイズのドキュメントをランダムに返します。
フォントサイズを URL にセレクターとして含めれば、この問題を回避できます。
www.myCompany.com/news/main.large.html
ほとんどのレイアウトの側面では、スタイルシートまたはクライアント側スクリプトを使用することもできます。通常、これらはキャッシュと非常にうまく連携します。
これは印刷版でも役立ちます。次のような URL を使用できます。
www.myCompany.com/news/main.print.html
テンプレートの定義のスクリプトグロブを使用すると、印刷ページをレンダリングする個別のスクリプトを指定できます。
ページタイトルまたはその他のテキストを写真としてレンダリングする場合は、そのファイルを、ページ上のコンテンツの更新時に自動的に削除されるような方法で格納することをお勧めします。
ページと同じフォルダーに画像ファイルを配置します。
画像ファイルに次の命名形式を使用します。
<page file name>.<image file name>
例えば、file myPage.title.gif
にページ のタイトル myPage.html
を格納できます。ページが更新されると、このファイルは自動的に削除されるので、ページタイトルに対する変更はキャッシュに自動的に反映されます。
画像ファイルは必ずしも AEM インスタンスに物理的に存在するわけではありません。画像ファイルを動的に作成するスクリプトを使用できます。そのファイルを Dispatcher が Web サーバーに格納します。
ナビゲーションエントリ用の写真を使用する場合の方法は、タイトルを使用する場合と基本的に同じですが、若干複雑になります。すべてのナビゲーション画像をターゲットページと共に格納します。通常用とアクティブ用の 2 つの写真を使用する場合は、次のスクリプトを使用できます。
ページと同じ命名ハンドルを使用してこれらの写真を作成し、コンテンツの更新によって写真とページが削除されるようにしてください。
変更されないページの場合、通常、そのページ自体は自動的に無効化されますが、写真はキャッシュに残ります。
パーソナライズ機能は必要な場所に制限することをお勧めします。その理由は次のとおりです。
Dispatcher キャッシュの設定について詳しくは、AEM Dispatcher Cache チュートリアルおよび保護されたコンテンツのキャッシュの節を参照してください。
各ページをパーソナライズする(例えば、ユーザー名をタイトルバーに挿入する)場合は、パフォーマンスに重大な影響を及ぼす可能性があります。
保護されたコンテンツのキャッシュについては、Dispatcher ガイドのセキュリティ保護されたコンテンツのキャッシュを参照してください。
1 つのページに制限付きコンテンツと公開コンテンツを混在させる場合、Dispatcher のサーバーサイドインクルードを利用する方法や、ブラウザーの Ajax 経由でクライアントサイドインクルードを利用する方法を検討できます。
公開コンテンツと制限コンテンツが混在している場合の処理については、Sling ダイナミックインクルードの設定を参照してください。
スティッキー接続を使用すると、1 人のユーザー用のドキュメントがすべて同じサーバーで作成されるようになります。ユーザーがそのフォルダーを離れて後から戻ってきた場合も、この接続は維持されます。これをおこなうには、Web サイトのスティッキー接続に必要なすべてのドキュメントを保持するためのフォルダーを 1 つ定義します。このフォルダーには他のドキュメントを格納しないようにします。そうすると、パーソナライズされたページとセッションデータを使用する場合に、ロードバランシングに影響が生じます。
ブラウザーがファイル形式を特定する方法は 2 つあります。
.html
、.gif
、.jpg
)ほとんどのファイルでは、MIME タイプがファイル拡張子に暗に含まれています。つまり、次の方法でファイル形式を特定できます。
.html
、.gif
、.jpg
)ファイル名に拡張子がない場合は、プレーンテキストとして表示されます。
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュできます。Dispatcher で応答ヘッダーをキャッシュしない場合は、MIME タイプが HTTP ヘッダーに含まれていることに注意してください。つまり、AEM アプリケーションから返されるファイルが、認識されたファイル拡張子を持たず、代わりに MIME タイプに依存する場合は、ファイルが正しく表示されない可能性があります。
ファイルが適切にキャッシュされるようにするには、次のガイドラインに従ってください。
download.jsp?file=2214
のような URL を持つ汎用のファイル提供スクリプトは避けます。スクリプトを書き直して、ファイル仕様を含む URL を使用してください。前の例では、download.2214.pdf
のようになります。この節では、AEMのバックアップのパフォーマンスと、バックアップアクティビティがアプリケーションのパフォーマンスに与える影響を評価するために使用される一連のベンチマークについて説明します。AEM のバックアップは、実行中にシステムに大きな負荷を与えます。これと、これらの影響を調整しようとするバックアップ遅延設定の影響を測定します。目的は、現実的な構成でのバックアップの期待されるパフォーマンスと実稼働データの量に関する参照データを提供し、計画されたシステムのバックアップ時間を見積もる方法に関するガイダンスを提供することです。
このドキュメントで報告された結果は、次の設定を使用した参照環境で実行されたベンチマークから取得されました。この設定は、データセンターの一般的な実稼働環境と似たように設計されています。
このサーバーのディスクサブシステムは非常に高速であり、実稼働サーバーで使用可能な高性能 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 がアイドル状態の場合にバックアップを実行することをお勧めしますが、システムに負荷がかかっている際にバックアップを実行しなければならない場合もあります。
バックアップ時間と生成されるバックアップのサイズは AEM サーバーのログから取得します。通常は、AEM がアイドル状態であるオフタイム(深夜など)にバックアップのスケジュールを設定することをお勧めします。このシナリオは、推奨されるアプローチを代表するものです。
負荷を構成するのは、ページの作成/削除、移動およびクエリーです。負荷の大部分はページの移動とクエリーによるものです。大量のページを追加および削除することでワークスペースのサイズが継続的に増加し、バックアップを完了できなくなります。スクリプトが使用する負荷の分散により、75 %がページの移動、24 %がクエリー、1 %がページの作成に割り当てられます(ネストされたサブページのない単一のレベル)。アイドル状態のシステムで 1 秒あたりの平均トランザクション数がピークに達するのは、4 つのスレッドを同時に使用した場合です。これは、負荷状態でのバックアップのテスト時に使用されます。
バックアップのパフォーマンスに負荷が及ぼす影響は、このアプリケーションによる負荷がある状態とない状態のパフォーマンスの差で見積もることができます。アプリケーションのスループットにバックアップが及ぼす影響は、同時バックアップを実行している状態と実行していない状態でのこのシナリオのトランザクションのスループット(1 時間あたり)と、異なる「バックアップ遅延」設定を使用してバックアップを実行している状態でのトランザクションのスループット(1 時間あたり)を比較して特定されます。
これらのベンチマークの主な結果から、バックアップの種類と全体的なデータ量の関数としてバックアップ時間がどのように変化するかを示すことができます。次のグラフは、デフォルトのバックアップ設定を使用して取得したバックアップ時間を、合計ページ数の関数として示しています。
アイドル状態のインスタンスでのバックアップ時間は、フルバックアップか増分バックアップかに関係なく平均 0.608 MB/s でほぼ一定です(下の図を参照)。バックアップ時間は単にバックアップされるデータ量の関数です。フルバックアップの完了に要する時間は、合計ページ数が増加すると明らかに長くなります。増分バックアップの完了に要する時間も合計ページ数が増加すると長くなりますが、はるかに低い割合です。増分バックアップの完了に要する時間が短いのは、バックアップ対象のデータが比較的少量であるためです。
生成されるバックアップのサイズは、バックアップの完了に要する時間の主要な決定要因です。次のグラフは、最終的なバックアップサイズの関数としてバックアップの所要時間を示しています。
このグラフでは、スループットとしての測定が可能なサイズと時間のシンプルな比較パターンに増分バックアップとフルバックアップの両方が従っていることがわかります。アイドル状態のインスタンスでのバックアップ時間は、ベンチマーク環境でフルバックアップと増分バックアップのどちらを実行しているかに関係なく、平均 0.61 MB/s でほぼ一定です。
バックアップ遅延パラメーターは、実稼働のワークロードに対するバックアップの影響の度合いを制限するために指定します。このパラメーターでは待機時間をミリ秒単位で指定します。指定した待機時間は、バックアップ操作においてファイル単位で適用されます。全体的な影響は、バックアップ対象のファイルのサイズにある程度左右されます。バックアップのパフォーマンスを MB/s 単位で測定すると、遅延がバックアップに及ぼす影響を合理的に比較できます。
比較のため、スループットを取得する際は、ファイルシステムバックアップ(「tar」を使用)を使用して同じリポジトリファイルをバックアップしました。tar のパフォーマンスは同等ですが、遅延をゼロに設定したバックアップよりもわずかに高くなります。わずかな遅延を設定しただけでもバックアップのスループットが大幅に減少します。デフォルトの遅延である 10 ミリ秒を使用すると、スループットはさらに減少します。アプリケーションの全体的な使用率が非常に低いとき、またはアプリケーションが完全にアイドル状態のときにバックアップのスケジュールを設定できる場合は、バックアップをより迅速に続行できるように、遅延をデフォルト値よりも小さくするのが望ましいでしょう。
実行中のバックアップのアプリケーションのスループットが及ぼす実際の影響は、アプリケーションとインフラストラクチャの詳細に左右されます。遅延値の選択はアプリケーションの実証的分析に基づいておこなう必要がありますが、できる限り迅速にバックアップを完了するには、遅延値をできる限り小さくしてください。遅延値の選択とアプリケーションのスループットに及ぼす影響との相関関係は低いので、バックアップが及ぼす全体的な影響を最小限に抑えるには、遅延の選択時に全体的なバックアップ時間が短くなるようにします。完了までに 8 時間かかり、スループットに -20 %の影響を及ぼすバックアップは、完了までに 2 時間かかり、スループットに -30 %の影響を及ぼすバックアップよりも全体的な影響が大きくなる可能性があります。