パフォーマンスの最適化 performance-optimization

Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。 応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。 この値が達成可能で維持可能であることが判明したら、それを使用して、web サイトのパフォーマンスを監視し、潜在的な問題が発生しつつあるときにそれを示すことができます。

ターゲットオーディエンスの特性が異なることを反映して、オーサー環境とパブリッシュ環境では、目標とする応答時間が異なります。

オーサー環境 author-environment

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

パブリッシュ環境 publish-environment

この環境には、ユーザーに公開するコンテンツが置かれます。 ここでは、リクエストの数がさらに多くなり、速度が極めて重要になります。 しかし、リクエストの性質はそれほど動的ではないので、コンテンツのキャッシュやロードバランシングなどの付加的なパフォーマンス強化メカニズムを適用できます。

パフォーマンスの最適化方法 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 ミリ秒未満に抑えます。 より具体的には、次のようなガイドラインに従います。

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

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

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

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

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

デジタルアセットの読み込みと編集時のパフォーマンス performance-when-loading-and-editing-digital-assets

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

この場合、次の 2 つの要素がパフォーマンスに影響します。

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

パフォーマンスの監視 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 ジョブキュー設定サービスファクトリから作成されました。

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

リポジトリでの設定 configuration-in-the-repo

sling:OsgiConfig ノード 🔗を使用してサービス を設定する場合は、既存のサービスのPID （例：org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705）を見つける必要があります。 Web コンソールを使用すると、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 用に設定されるトピックに一致します。

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

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

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

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

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 インスタンスをデプロイすると、パフォーマンスの強化に役立ちます。例えば、次のような場合です。

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

品質保証のベストプラクティス best-practices-for-quality-assurance

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

この節では、特に​ パブリッシュ ​環境のパフォーマンステストのテストコンセプトを定義する際の問題を標準的な観点から概説します。 この情報は、主に QA エンジニア、プロジェクトマネージャーおよびシステム管理者向けの内容となっています。

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

制御は、すべてを包含する追加のプロセスであり、テストに必要ですが、それに限定されるものではありません。

知識の検証 verification-of-knowledge

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

アーキテクチャのテスト test-architecture

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

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

アプリケーションマップ application-map

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

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

範囲の定義 scope-definition

通常、アプリケーションには様々なユースケースがあります。 重要なユースケースもあれば、それほど重要でないものもあります。

パブリッシュでのパフォーマンステストの範囲を絞り込むために、以下を定義することをお勧めします。

ユースケースの数は状況に応じて異なりますが、管理しやすい数（例えば 5～10）に制限する必要があります。

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

テスト方法 test-methodologies

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

次の原則に基づきます。

コンポーネントのブレークポイント component-breakpoints

トランザクション transactions

パフォーマンス目標の定義 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

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

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

例えば、リクエスト総数が 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 つあります。

        <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

URL でカスタマイズ customize-by-url

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

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

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

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

タイトルとして使用されている画像ファイルの無効化 invalidating-image-files-used-as-titles

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

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

ナビゲーションに使用された画像ファイルの無効化 invalidating-image-files-used-for-navigation

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

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

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

パーソナライズ機能 personalization

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

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

1 つのページに制限付きコンテンツと公開コンテンツを混在させる場合、Dispatcher のサーバーサイドインクルードを利用する方法や、ブラウザーの Ajax 経由でクライアントサイドインクルードを利用する方法を検討します。

スティッキー接続 sticky-connections

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

MIME タイプ mime-types

ブラウザーがファイルのタイプを判別する方法は 2 とおりあります。

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

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

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

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