パフォーマンスに関する一般的なガイドラインについては、 パフォーマンスガイドライン ページ。
パフォーマンスの問題のトラブルシューティングと修正について詳しくは、 パフォーマンスツリー.
また、ナレッジベースの記事を パフォーマンスチューニングのヒント.
主な問題は、Web サイトが訪問者のリクエストに応答するのに要する時間です。 この値はリクエストごとに異なりますが、平均ターゲット値を定義することもできます。 この値が達成可能で維持可能であることが判明したら、Web サイトのパフォーマンスを監視し、潜在的な問題の発生を示すために使用できます。
対象オーディエンスの様々な特性を反映し、オーサー環境とパブリッシュ環境では、対象となる応答時間が異なります。
この環境は、作成者がコンテンツを入力および更新する際に使用します。 コンテンツページとそれらのページの個々の要素を更新する際に、パフォーマンスを集中的に消費するリクエストの数が多い数のユーザーに対して注意する必要があります。
この環境には、ユーザーが使用できるようにするコンテンツが含まれています。 ここでは、リクエストの数がさらに多くなり、速度も非常に重要です。 しかし、要求の性質は動的ではないので、追加のパフォーマンス向上メカニズムを適用できます。例えば、コンテンツのキャッシュやロードバランシングをおこなう場合などです。
AEM Projects のパフォーマンス最適化手法は、5 つのシンプルなルールにまとめて、最初からパフォーマンスの問題を回避するために従うことができます。
これらのルールは、一般に Web プロジェクトに適用され、プロジェクトマネージャーやシステム管理者に関連しており、起動時にプロジェクトのパフォーマンスに関する課題が発生しないようにします。
パフォーマンス最適化フェーズでは、プロジェクト作業の約 10%を計画します。 実際のパフォーマンス最適化要件は、プロジェクトの複雑さのレベルと開発チームの経験によって異なります。 プロジェクトに割り当てられた時間が(最終的に)必要ない場合がありますが、推奨地域でのパフォーマンス最適化を常に計画することをお勧めします。
可能な限り、プロジェクトは限られたオーディエンスに対してソフトローンチし、実際のエクスペリエンスを収集し、完全な発表に続く追加の圧力なしに、さらに最適化を実行する必要があります。
「ライブ」になった後は、パフォーマンスの最適化は終了しません。 現在は、システムで「実際」の負荷が発生しています。 起動後に追加の調整を計画することが重要です。
システムの負荷が変わり、システムのパフォーマンスプロファイルが時間の経過と共に変化するので、パフォーマンスの「調整」または「ヘルスチェック」は 6 ~ 12 ヶ月間隔でスケジュールする必要があります。
Web サイトを利用して運用を開始し、起動後にパフォーマンスの問題が発生した場合は、負荷テストとパフォーマンステストが十分に実際の動作をシミュレートしていなかった可能性が高くなります。
現実のシミュレーションは難しく、「現実」を得るためにどれだけの労力を費やしたいかは、プロジェクトの性質によって決まります。 「実際」とは、「実際のコード」と「実際のトラフィック」だけでなく、特にコンテンツのサイズと構造に関して、「実際のコンテンツ」を意味します。 テンプレートの動作は、リポジトリのサイズと構造によって異なる場合があります。
パフォーマンス目標を適切に設定することの重要性は、過小評価されてはいけません。 多くの場合、特定のパフォーマンス目標に焦点を当てた後は、仮定に基づいている場合でも、後でこれらの目標を変更するのは困難です。
優れた、確実なパフォーマンス目標を確立することは、実際に最も難しい領域の 1 つです。 多くの場合、同等の Web サイト(新しい Web サイトの前に使用した Web サイトなど)から実際のログとベンチマークを収集するのが最適です。
ボトルネックは一度に 1 つずつ最適化することが重要です。 1 つの最適化の影響を検証せずに並行して処理を行おうとすると、どの最適化測定が役立ったかを追跡できなくなる場合があります。
パフォーマンスの調整は、目標に達するまで、測定、分析、最適化、検証を繰り返しおこなうプロセスです。 この点を考慮するには、各反復後に、より重いテストプロセスではなく、最適化フェーズに機敏な検証プロセスを実装します。
つまり、最適化を実装する開発者は、最適化が既に目標に達しているかどうかをすばやく確認できる必要があります。 この情報は役に立ちます。目標を達成すると、最適化が完了するからです。
一般に、キャッシュされていない HTML リクエストは 100 ミリ秒未満に抑えてください。 具体的には、次のようなガイドラインが役立つ場合があります。
上記の数値は、次の条件を前提としています。
パフォーマンスの問題に頻繁に影響を与える問題がいくつかあります。例えば、次のような問題です。
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 サービスファクトリで既存の設定項目を特定します。
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 アセットの更新ワークフローを使用して、ワークフロー用のジョブキューを作成します。
ジョブキューを作成する対象となるワークフローモデルを実行します。これにより、トピックの統計が生成されます。例えば、アセットに画像を追加して、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、ロードバランサーと共に複製する必要があります。
アプリケーション全体のマップを作成できる明確な概要を示します(オーサー環境のテストから既にこのマップを持っている場合もあります)。
アプリケーションの内部要素を図で示し、テスト要件の概要を示します。色分けを使用することで、レポートの基礎としても機能します。
通常、アプリケーションには様々な用途があります。 重要な使用例もあれば、重要でない使用例もあります。
公開時にパフォーマンステストの範囲を絞り込むには、Adobeで次の項目を定義することをお勧めします。
使用例の数は自分次第ですが、管理しやすい数(例:5 ~ 10)に制限する必要があります。
主要なユースケースを選択したら、主要業績評価指標 (KPI) とそれらの測定に使用するツールをケースごとに定義できます。 一般的な KPI の例を次に示します。
この概念には、パフォーマンス目標の定義とテストに使用する 4 つのシナリオがあります。
次の原則に基づきます。
範囲と関連する 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 | オーサー動作のシミュレーション。 |
実装の後の段階で、パフォーマンス目標を満たし、最大化するようにアプリケーションを最適化します。
実施した最適化をすべてテストして、次の点を確認してください。
ロードジェネレーション、パフォーマンス監視、結果分析に役立つ様々なツールを利用できます。 これらのツールの一部を次に示します。
最適化後、再度テストして影響を確認します。
継続的なレポートにより、すべてのユーザーが状況を把握できます。 前述のように、色分けでは、アーキテクチャマップをこの状態に使用できます。
すべてのテストが完了したら、次の情報を報告します。
この Dispatcher は、Adobeのキャッシュやロードバランシングを行うツールです。 Dispatcher を使用する場合は、キャッシュパフォーマンスを確保するために Web サイトの最適化を検討してください。
Dispatcher のバージョンはAEMとは独立していますが、Dispatcher のドキュメントはAEMのドキュメントに埋め込まれています。 最新バージョンのAEMのドキュメントに埋め込まれている Dispatcher のドキュメントを必ず使用してください。
以前のバージョンのAEMのドキュメントに埋め込まれている Dispatcher ドキュメントへのリンクをたどった場合は、このページにリダイレクトされている可能性があります。
Dispatcher には、Web サイトでパフォーマンスを活用する場合にパフォーマンスを最適化するために使用できる、いくつかの組み込みメカニズムが用意されています。 この節では、キャッシュのメリットを最大限に活用するために Web サイトをデザインする方法について説明します。
Dispatcher が標準の Web サーバーにキャッシュを保存することを忘れないでください。 この情報を把握することで、URL を使用して、ページとして保存したり、リクエストしたりできるすべての項目をキャッシュできるようになります。 また、cookie、セッションデータ、フォームデータなど、その他のものを保存することはできません。
一般に、多くのキャッシュ戦略では、適切な URL を選択することが含まれ、この追加データに依存しません。
Dispatcher バージョン 4.1.11 では、応答ヘッダーをキャッシュすることもできます。HTTP 応答ヘッダーのキャッシュを参照してください。
キャッシュ率の数式では、システムに入ってくる要求の合計数の中から、キャッシュによって処理される要求の割合を推定します。 キャッシュ率を計算するには、次の情報が必要です。
要求の総数。この情報は、Apache の access.log
で確認できます。詳しくは、 公式の Apache ドキュメント.
パブリッシュインスタンスが提供した要求の数。 この情報は、インスタンスの request.log
で確認できます。詳しくは、request.log の解釈およびログファイルの検索を参照してください。
キャッシュ率の計算式は次のとおりです。
例えば、要求の合計数が129491で、パブリッシュインスタンスが提供する要求の数が58959の場合、キャッシュの比率は次のようになります。 (129491 - 58959)/129491= 54.5%.
1 対 1 のパブリッシャーと Dispatcher の組み合わせがない場合は、すべての Dispatcher とパブリッシャーからのリクエストを一緒に追加して、正確な測定をおこなうことができます。 関連トピック 推奨されるデプロイメント.
最高のパフォーマンスを得るために、Adobeではキャッシュの比率を 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 チュートリアルおよび保護されたコンテンツのキャッシュの節を参照してください。
(例えば)ユーザーの名前をタイトルバーに入れて各ページをパーソナライズすると、パフォーマンスに影響を与えます。
セキュリティ保護されたコンテンツのキャッシュについては、 セキュリティ保護されたコンテンツのキャッシュ を参照してください。
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 を使用するには、スクリプトを書き換えます。 前の例では、次の書き換えがおこなわれます。 download.2214.pdf
.この節では、AEMのバックアップのパフォーマンスと、バックアップアクティビティがアプリケーションのパフォーマンスに与える影響を評価するために使用される一連のベンチマークについて説明します。AEMのバックアップは、実行中にシステムに大きな負荷を与え、Adobeはこの影響と、これらの影響を調整しようとするバックアップ遅延設定の影響を測定します。 目的は、現実的な構成でのバックアップの期待されるパフォーマンスと実稼働データの量に関する参照データを提供し、計画されたシステムのバックアップ時間を見積もる方法に関するガイダンスを提供することです。
このドキュメントで報告された結果は、次の設定を使用した参照環境で実行されたベンチマークから取得されました。この設定は、データセンターでの一般的な実稼動環境に似ています。
このサーバのディスクサブシステムは高速で、本番サーバで使用される可能性のある高パフォーマンス 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 サーバーのログから取得します。通常は、AEM がアイドル状態であるオフタイム(深夜など)にバックアップのスケジュールを設定することをお勧めします。このシナリオは、推奨されるアプローチを表しています。
Load は、作成されたページ、削除されたページ、トラバーサル、およびページのトラバーサルとクエリからのほとんどの負荷を含むクエリで構成されます。 多数のページを追加または削除すると、ワークスペースのサイズが継続的に増加し、バックアップが完了しなくなります。 スクリプトで使用される読み込みの分布は、75%のページトラバーサル、24%のクエリ、1%のページ作成です(ネストされたサブページのない単一レベル)。 アイドルシステムでの 1 秒あたりのピーク平均トランザクション数は、4 つの同時スレッドを使用して達成されます。これは、負荷の下でバックアップをテストする際に使用されます。
このアプリケーションの負荷の有無によるパフォーマンスの違いによって、バックアップのパフォーマンスに対する負荷の影響を予測できます。 1 時間あたりのトランザクションのシナリオのスループットを、同時バックアップを継続して行う場合と行わない場合、および異なる「バックアップ遅延」設定で動作するバックアップと比較すると、バックアップのアプリケーションスループットへの影響が見られます。
これらのベンチマークの主な結果は、バックアップの種類と全体的なデータ量の関数に応じてバックアップ時間がどの程度変化するかを示すことです。 次の図は、合計ページ数の関数として、デフォルトのバックアップ構成を使用して取得したバックアップ時間を示しています。
アイドル状態のインスタンスのバックアップ時間は、フル・バックアップまたは増分バックアップに関係なく、1 秒あたり平均 0.608 MB/秒で、かなり一貫しています(下図を参照)。 バックアップ時間は、バックアップされるデータ量の関数に過ぎません。 フル・バックアップの完了に要する時間は、合計ページ数と共に明らかに増加します。 増分バックアップの完了に要する時間も合計ページ数で増加しますが、かなり低い速度で進みます。 増分バックアップの完了に要する時間は、バックアップされるデータ量が比較的少ないため、はるかに短くなります。
生成されるバックアップのサイズは、バックアップの完了に要する時間の主な決定要因です。 次のグラフは、最終的なバックアップ・サイズの関数としての所要時間を示しています。
この図は、増分バックアップとフル・バックアップの両方が、Adobeがスループットとして測定できるシンプルなサイズと時間のパターンに従うことを示しています。 アイドル状態のインスタンスのバックアップ時間は、ベンチマーク環境でのフルバックアップまたは増分バックアップに関係なく、1 秒あたり平均 0.61 MB/秒でかなり一貫しています。
バックアップ遅延パラメータが提供され、バックアップが本番ワークロードに影響を与える可能性のある範囲を制限します。 このパラメータは、待ち時間をミリ秒単位で指定します。この値は、ファイル単位でバックアップ操作に割り当てられます。 全体的な効果は、影響を受けるファイルのサイズによって一部異なります。 MB/秒でバックアップのパフォーマンスを測定すると、バックアップに対する遅延の影響を比較するのに適した方法が得られます。
比較のために、同じリポジトリファイルをバックアップするためにファイルシステムのバックアップ (「tar」) を使用して取得したスループット。 tar のパフォーマンスは同等ですが、遅延が 0 に設定されたバックアップよりも若干高くなります。 遅延を小さく設定しても、バックアップのスループットが大幅に低下し、10 ミリ秒のデフォルトの遅延により、スループットが大幅に低下します。 アプリケーションの全体的な使用率が低い場合や、アプリケーションがアイドル状態の場合にバックアップをスケジュールする場合は、デフォルト値を下回る遅延を減らして、バックアップをより迅速に実行できます。
継続的なバックアップのアプリケーション・スループットの実際の影響は、アプリケーションとインフラストラクチャの詳細によって異なります。 遅延値の選択は、アプリケーションの経験的な分析によって行う必要がありますが、バックアップを可能な限り迅速に完了できるように、できる限り小さな値を選択する必要があります。 遅延値の選択とアプリケーションのスループットへの影響には弱い相関があるので、遅延を選択すると全体的なバックアップ時間を短くして、バックアップ全体の影響を最小限に抑える必要があります。 8 時間かかり、スループットに —20%の影響を与えるバックアップは、完了までに 2 時間かかり、スループットに —30%の影響を与える場合よりも全体的な影響が大きくなる可能性があります。