パフォーマンスの最適化

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

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

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

この環境には、ユーザー向けに提供するコンテンツが置かれます。したがって要求数は非常に多く、速度が非常に重要となります。ただし、それらの要求の性質はさほど動的な内容ではないので、コンテンツのキャッシュや負荷分散などの付加的なパフォーマンス強化メカニズムを適用できます。

CQ プロジェクトのパフォーマンスを最適化する方法は、5 つの非常に単純なルールに要約されます。それらのルールを守れば、パフォーマンスの問題が発生するのを最初から防ぐことができます。

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

各ルールの内容は一般的な Web プロジェクトすべてに当てはまる部分が多く、プロジェクトマネージャーやシステム管理者にとっては、プロジェクトの稼動開始時にパフォーマンスの問題に悩まされないようにするために有効です。

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

プロジェクトの稼動開始当初は、可能な限り、少ないユーザーを対象として緩やかに運用を開始するのが望ましいと考えられます。そうすれば、全面的なサービス公開による過大なプレッシャーにさらされることなく、本番の経験を蓄積して最適化をいっそう進めることができるからです。

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

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

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

実際の状況に近いシミュレーションをおこなうのは難しいことであり、「実際」の追求にどこまで手間をかけるかは、プロジェクトの性質に応じた無理のない範囲で判断する必要があります。「実際」とは、「実際のコード」や「実際のトラフィック」に限りません。「実際のコンテンツ」、特にコンテンツのサイズや構造が実際的であることも重要です。リポジトリのサイズや構造が変われば、テンプレートの挙動はまったく違ってくる可能性があるということを常に意識してください。

適切なパフォーマンス目標を設定することの重要性を軽視してはいけません。何らかのパフォーマンス目標に基づく活動を一旦開始すると、たとえその目標に確かな根拠がないとしても、後で軌道修正することは非常に困難です。

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

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

パフォーマンスのチューニングは、目標を達成するまで測定、分析、最適化および検証のサイクルを続ける反復的なプロセスです。この性質を考えると、サイクルを 1 周するごとに後で大がかりなテストプロセスを実施するよりも、最適化フェーズ内でアジャイルな検証プロセスを実施するほうがよいと考えられます。

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

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

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

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

• パブリッシュ環境で測定（オーサー環境に関連するオーバーヘッドがない）
• サーバー上で測定（ネットワークオーバーヘッドを考慮しない）
• キャッシュなし（CQ-output キャッシュや Dispatcher キャッシュを考慮しない）
• 多数の依存ファイル（HTML、JS、PDF など）を伴う複雑な要求のみ
• 他のシステム負荷なし

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

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

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

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

たいていのパフォーマンス最適化で扱う対象を次に示します。

• request.log
• コンポーネント別の時間計測
• Java プロファイラー

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

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

• CPU - 複数のコアがあると、トランスコーディングの際に処理がスムーズにおこなわれます。
• ハードディスク - 並列の RAID ディスクを使用すると、同じ効果がもたらされます。

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

• 1 日にアップロードするアセットの数。次の式を基に概算できます。
  

• 編集がおこなわれる時間（通常は営業日の長さ。海外との業務がある場合はより多くの時間が必要）。
• アップロードする画像の MB 単位の平均サイズ（および 1 つの画像につき生成されるレンディションのサイズ）。
• 平均データレートは次の式で算出されます。
  

• すべての編集の 80 ％は 20 ％の時間内におこなわれるので、ピーク時には平均データレートが 4 倍になります。これがパフォーマンスの目標です。

パフォーマンス（またはパフォーマンスの欠如）はユーザーが最初に認識する点の 1 つなので、ユーザーインターフェイスを使用するアプリケーションと同様に、パフォーマンスは非常に重要です。CQ インストールのパフォーマンスを最適化するには、インスタンスの様々な属性とインスタンスの動作を監視する必要があります。

パフォーマンスの監視を実行する方法について詳しくは、パフォーマンスの監視を参照してください。

多くの場合、パフォーマンスの問題を引き起こす原因を見つけ出すのは、その影響が明白であったとしても困難です。

基本となる開始点は、通常稼動時のシステムを熟知することです。適切に稼動する環境がどのように「見え」て「動作する」かを把握していない限り、パフォーマンスが低下した際に問題を特定するのは難しくなります。つまり、スムーズに稼動しているシステムの調査に時間を費やし、パフォーマンスの情報を継続して収集する必要があります。この情報に基づいて、パフォーマンスが低下した場合に比較をおこなうことができます。

次の図は、CQ コンテンツの要求のパスおよびパフォーマンスに影響を及ぼす可能性のある様々な要素を示しています。

パフォーマンスは、ボリュームと処理能力のバランスでもあります。

これを Web チェーン全体の様々な場所で示すことができます。

多くの場合、複数の機能領域がパフォーマンスに影響を及ぼす原因となります。

• キャッシュ
• アプリケーション（プロジェクト）コード
• 検索機能

パフォーマンスを最適化する場合は、次に示すルールを常に意識してください。

• パフォーマンスのチューニングを各プロジェクトでおこなう。
• 開発サイクルの初期に最適化をおこなわない。
• パフォーマンスはシステムの最も弱い部分に左右される。
• 常に処理能力とボリュームを比較して考える。
• 重要な要素を最初に最適化する。
• 必ず現実的な目標を設定してから最適化を実施する。

パフォーマンスを最適化するために CQ（および基盤となる CRX）の特定の要素を設定できます。設定可能な要素と推奨事項を次に示します。変更をおこなう前に、記載されている機能を使用するかどうか、またはどのように使用するかを確認しておく必要があります。

検索結果のハイライト表示を使用しない場合は、<SearchIndex> 要素でハイライト表示のサポートを無効にして、検索インデックスのサイズを大幅に削減できます。

（ほとんどの場合、システム）プロパティの「フルテキスト」インデックスを作成しないようにすることで、検索インデックスを削減できます。例えば、CQ 5.3 では、デフォルトのファイル内の次のストップリストが大幅に拡張されています。

    crx-quickstart/server/runtime/0/crx/WEB-INF/classes/indexing_config.xml

必要に応じて、適切なリストの項目を追加または削除できます。

jcr クエリーの結果セットのサイズが大きい場合は、すべての結果セットの読み込みとその ACL の確認に多くの負荷がかかります。この問題を修正するには、workspace.xml の SearchIndex 要素を使用して、フェッチサイズを（一例として）50 に設定します。

ドキュメント番号のキャッシュのサイズを定義します。このキャッシュは、UUID を Lucene ドキュメント番号にマップします。

ログには、キャッシュの効率を示す INFO メッセージが（随時）記録されます。

cacheRatio が常に 90 ％を下回っている場合は、キャッシュサイズを増やす必要があります。cacheSize パラメーターは、workspace.xml の SearchIndex 要素で設定できます。次に例を示します。

ノードとそのすべてのプロパティで構成されるバンドルをキャッシュします。このキャッシュは、バンドルベースのすべての永続性マネージャーで使用されます。

BundleCache のデフォルトサイズは 8 MB です。このサイズが小さすぎると、基盤となる永続性レイヤーに対する過剰な数の読み取りアクセスが発生する可能性があります。

ログの各行は、キャッシュサイズが小さすぎるタイミングを示します。この情報は、*INFO* レベルで定期的に CRX ログ（crx-quickstart/logs/crx/error.log）に記録されます。

この例に示す内容は次のとおりです。

• 2,860 項目のバンドルがキャッシュされる
  
• 8,189 KB のメモリを使用する
• 許容される最大キャッシュサイズ：8,192 KB（デフォルト値の 8 MB）
  
• 平均バンドルサイズ：2,932 バイト
• ヒット数：1,200 万
  
• ミス数：600 万
• つまり、2 回に 1 回のアクセスがミスとなる
  

このような場合は、バンドルキャッシュのサイズが（JVM に割り当てることのできるメモリの容量に応じて）、例えば 256 MB、512 MB または 1 GB に増加する可能性があります。例えば、Xmx パラメーターが 10 GB に設定された JVM がある場合は、bundleCacheSize を 1024 に設定する必要があります。

そのためには、bundleCacheSize パラメーターを使用して <PersistenceManager> 要素の設定を拡張します。値は数値であり、MB 単位のサイズを示します（次の例では 512 MB です）。

パフォーマンスを向上するには、同時に実行するワークフロープロセスの数を制限します。デフォルトでは、Java VM で使用可能なプロセッサーの数だけ、ワークフローエンジンがワークフローを並行して処理します。ワークフローのステップで大量の処理リソース（RAM または CPU）が必要な場合は、それらのワークフローの一部を並行して実行する際に、使用可能なサーバーリソースに対する需要が高まる可能性があります。 

例えば、画像（通常は DAM アセット）がアップロードされると、ワークフローではその画像が自動的に DAM に読み込まれます。多くの場合、画像は高解像度であり、処理のために数百 MB のヒープをすぐに消費します。このような画像を並行して処理すると、メモリのサブシステムとガベージコレクターに大きな負荷がかかります。

ワークフローエンジンでは、Apache Sling のジョブキューを使用して、作業項目の処理の対応およびスケジュール設定をおこないます。デフォルトでは、ワークフロージョブの処理用に、Apache Sling Job Queue Configuration サービスファクトリから次のジョブキューサービスが作成されています。

• Granite Workflow Queue：ワークフローのほとんどのステップ（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 サービスファクトリで既存の設定項目を特定します。

「並列ジョブの最大数」という名前のプロパティを設定する必要があります。

特定のワークフローモデル用のジョブキューを作成して、そのワークフローモデル用のジョブの処理を設定できるようにします。この方法では、設定が特定のワークフロー用の処理に影響を及ぼします。一方、デフォルトの 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 アセットの更新ワークフローを使用して、ワークフロー用のジョブキューを作成します。

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

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

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

• オーサー環境用の多数のアセットの定期的なアップロードが原因で負荷が高い。この場合、別の専用の DAM インスタンスがオーサー環境にサービスを提供します。
• 世界各国に複数のチームが存在する（米国、ヨーロッパ、アジアなど）。

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

• オーサーの「処理中の作業」とパブリッシュの「最終版」を分離する
• オーサーの内部ユーザーとパブリッシュの外部の訪問者／ユーザー（代理人、報道関係者、顧客、受講生など）を分離する

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

ここでは、パブリッシュ環境におけるパフォーマンステストに特化したテスト概念の定義に関連する問題の標準化された概要を示します。これは主に QA エンジニア、プロジェクトマネージャーおよびシステム管理者に役立つ情報です。

以降に示すのは、パブリッシュ環境でおこなう CQ アプリケーションのパフォーマンステストに対する標準化されたアプローチです。次の 5 つのフェーズがあります。

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

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

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

• テスト環境のアーキテクチャ
• テストに必要な内部要素を詳細に示したアプリケーションマップ（単体で使用する場合と組み合わせて使用する場合の両方）

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

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

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

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

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

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

• 最も重要な業務上の事例
• 最も不可欠な技術上の事例

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

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

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

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

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

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

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

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

トランザクション

• トランザクションという用語は、完全な Web ページの要求を表すために使用します。この要求には、ページ自体および後続のすべての呼び出し（ページ要求、AJAX 呼び出し、画像およびその他のオブジェクト）が含まれます。要求のドリルダウン

• 各要求をすべて分析するために、コールスタックの各要素を表してから、各要求の平均処理時間の合計を求めることができます。

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

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

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

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

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

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

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

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

• ユーザーが検索ボックスに検索用語を入力しようとするとどうなるか
• 検索用語が一般的すぎて、返される結果の数が非常に多い場合はどうなるか

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

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

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

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

• 機能に影響を及ぼさない 
• リリース前に負荷テストを実施して検証済みである

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

• JMeter
• Load Runner（HP）
• Determyne InsideApps
• InfraRED
• Java Interactive Profile
• その他の様々なツール

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

すべてのユーザーが常にステータスを把握できるようにするために、継続的にレポートを作成する必要があります。前述のとおり、色分けしたアーキテクチャマップをこの目的で使用できます。

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

• 発生した重大なエラー
• 重大でない問題（詳細な調査は必要）
• テスト中の想定事項
• テストから得られた推奨事項

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

HTTP 要求ヘッダーはキャッシュされないので、ページエンコーディング情報をヘッダーに格納すると、問題が発生する可能性があります。この場合、Dispatcher がキャッシュからページを提供すると、Web サーバーのデフォルトのエンコーディングがそのページに使用されます。この問題を回避する方法は 2 つあります。

• 使用するエンコーディングが 1 つだけの場合は、Web サーバーで使用するエンコーディングが AEM の Web サイトのデフォルトのエンコーディングと同じであることを確認します。
• <META> タグを HTML の head セクションで使用して、エンコーディングを設定します。次に例を示します。

可能な限り、キャッシュするページには URL パラメーターを使用しないでください。例えば、サイトに写真ギャラリーがあるとします。このとき、次の URL はキャッシュされません（Dispatcher が適切に設定されている場合を除く）。

ユーザーによるフォントサイズの変更（またはその他の任意のレイアウトのカスタマイズ）を許可する場合は、それぞれのカスタマイズが URL に反映されるようにする必要があります。

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

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

ページタイトルまたはその他のテキストを写真としてレンダリングする場合は、そのファイルを、ページ上のコンテンツの更新時に自動的に削除されるような方法で格納することをお勧めします。

1. ページと同じフォルダーに画像ファイルを配置します。
2. 画像ファイルに次の命名形式を使用します。
   
   <page file name>.<image file name>

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

ナビゲーションエントリ用の写真を使用する場合の方法は、タイトルを使用する場合と基本的に同じですが、若干複雑になります。すべてのナビゲーション画像をターゲットページと共に格納します。通常用とアクティブ用の 2 つの写真を使用する場合は、次のスクリプトを使用できます。

• 通常どおりにページを表示するスクリプト
• 「.normal」要求を処理して、通常の写真を返すスクリプト
• 「.active」要求を処理して、アクティベートされた写真を返すスクリプト

ページと同じ命名ハンドルを使用してこれらの写真を作成し、コンテンツの更新によって写真とページが削除されるようにしてください。

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

Dispatcher はパーソナライズされたデータをキャッシュできないので、パーソナライズは必要な場所にのみ適用することをお勧めします。その理由は次のとおりです。

• 開始ページを自由にカスタマイズ可能にした場合は、ユーザーからそのページを要求されるたびにページを構築する必要があります。
• 一方、10 個の異なる開始ページのなかから選択するようにした場合は、各ページをキャッシュしてパフォーマンスを強化できます。

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

ブラウザーがファイル形式を特定する方法は 2 つあります。

1. 拡張子（.html、.gif、.jpg など）
2. サーバーがファイルと共に送信する MIME タイプ

ほとんどのファイルでは、MIME タイプがファイル拡張子に暗に含まれています。つまり、次の方法でファイル形式を特定できます。

1. 拡張子（.html、.gif、.jpg など）
2. サーバーがファイルと共に送信する MIME タイプ

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

MIME タイプは HTTP ヘッダーに含まれており、Dispatcher は HTTP ヘッダーをキャッシュしません。AEM アプリケーションから返されるファイルが、認識されたファイル拡張子を持たず、代わりに MIME タイプに依存する場合は、ファイルが正しく表示されない可能性があります。

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

• ファイルに必ず適切な拡張子を含めます。
• 「download.jsp?file=2214」のような URL を含む汎用的なファイル提供スクリプトの使用を避けます。代わりに、ファイル仕様を含む URL を使用するようにスクリプトを書き直します（前述の例ならば「download.2214.pdf」となります）。

ここでは、CQ バックアップのパフォーマンスおよびバックアップアクティビティがアプリケーションのパフォーマンスに及ぼす影響の評価に使用する一連のベンチマークを紹介します。CQ バックアップの実行中はシステムに大きな負荷がかかります。その負荷と負荷を調整するためのバックアップ遅延設定の影響を測定します。現実的な設定と量の実稼働データで予想されるバックアップのパフォーマンスに関する参照データを提供することと、計画したシステムのバックアップ時間の見積もり方法に関するガイダンスを示すことが目標です。

このドキュメントでレポートされている結果は、次の設定を使用する参照用の環境で実行されたベンチマークから取得したものです。この設定は、データセンター内の一般的な実稼動環境と同様に設計されています。

• 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）
• CQ 5.5 GM を実行する単一のオーサーインスタンス

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

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

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

バックアップのベンチマークは、それぞれにコンテンツセットを追加して繰り返されます。

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

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

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

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

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

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

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

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

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

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

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

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

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