現在表示中:

概要

パフォーマンステストは、AEM をデプロイするうえで重要な役割を担っています。顧客の要件に応じて、パブリッシュインスタンスかオーサーインスタンスのどちらか一方またはその両方でパフォーマンステストを実施します。

このドキュメントでは、全体的な戦略とパフォーマンステストの実行方法を概説するほか、アドビが提供するテスト支援ツールをいくつか紹介します。最後に、コード分析とシステム設定の両観点から、AEM 6 でのパフォーマンス調整に役立つツールをいくつか取り上げます。

実際の状況に近いシミュレーション

パフォーマンステストを実行するときに最も重要なのは、可能な限り実稼動環境に近い状況を再現することです。これは簡単なことではありませんが、正確なパフォーマンステストをおこなうには不可欠です。パフォーマンステストを設計する際は、以下の点を考慮することが重要です。

  • 実稼動環境と同様のコンテンツ

クエリ応答時間など、AEM でのパフォーマンス指標の多くは、システム上のコンテンツのサイズの影響を受けます。実稼動環境のデータにできるだけ近いコピーをテスト環境に用意することが重要です。

  • 実稼動環境のコード

実稼動環境でデプロイする AEM のバージョンとホットフィックスは、テスト環境と同じである必要があります。実稼動環境にデプロイするコードのバージョンをテストすることも重要です。

  • 実稼動環境と同様のハードウェアとネットワーク設定

意味のあるテストをおこなうには、実稼動環境にできる限り似せた環境を用意することが必要です。できれば、テスト環境と実稼動環境の両方で、同じハードウェア仕様、ネットワークインターフェイス、ロードバランサーおよび CDN を使用することが理想です。

  • 実稼動環境の負荷

パフォーマンス問題の多くは、システムが高負荷状態になるまで認識されません。パフォーマンステストでは、実稼動システムのピーク時の負荷をシミュレートする必要があります。

目標の設定

パフォーマンステストを開始する前に、負荷と応答時間を指定するための非機能要件を設定する必要があります。既存のシステムから移行する場合は、応答時間が現在の稼動時の値に近いかを確認します。負荷に関しては、現在のピーク負荷の 2 倍を想定します。こうしておけば、Web サイトが拡大しても十分なパフォーマンスが維持されることを保証できます。

ツール

市販のパフォーマンステストツールは数多く存在します。負荷発生ツールを実行するときは、テストを実行するコンピューターに十分なネットワーク帯域幅を用意することが重要です。そうしないと、テストマシンが接続の限界に達した場合に、テスト対象の環境にさらなる負荷をかけることができなくなります。

テストツール

  • アドビの Tough Day ツールは、AEM インスタンスに負荷を発生させ、パフォーマンスデータを収集するために使用できます。アドビの AEM エンジニアリングチームは実際にこのツールを使用して、AEM 製品の負荷テストを実施しています。Tough Day で実行されるスクリプトは、プロパティファイルと JMX XML ファイルによって設定されています。詳しくは、Tough Day に関するドキュメントを参照してください。
  • AEM にはすぐに使用できるツールが備わっており、問題のあるクエリ、リクエスト、エラーメッセージを素早く確認できます。詳しくは、操作ダッシュボードのドキュメントの診断ツールの節を参照してください。
  • Apache は JMeter という製品を提供しています。これは、パフォーマンスおよび負荷テストのほか、機能的性能の確認のために使用できます。オープンソースソフトウェアであり自由に使用できますが、エンタープライズ製品よりも機能セットが少なく、容易に習熟できます。JMeter は Apache の Web サイト(http://jmeter.apache.org/)で入手できます。
  • Load Runner は HP が製造するエンタープライズレベルの負荷テスト製品です。無償評価版が提供されています。詳しくは、HP の Web サイト(http://www8.hp.com/us/en/software-solutions/loadrunner-load-testing/)を参照してください。
  • Neustar のようなクラウドベースの負荷テストツールも使用できます。
  • モバイルまたはレスポンシブ Web サイトをテストする際は、また別のツールセットを使用する必要があります。こうしたツールでは、ネットワーク帯域幅の制限、3G や EDGE などの低速なモバイル接続のシミュレートをおこなえます。広く利用されているツールには以下のものがあります。
    • Network Link Conditioner - 簡単に使用できる UI を備えており、またかなり低いレベルのネットワークスタックで動作します。OS X と iOS のバージョンがあります。
    • Charles - ネットワーク制限を使用できる Web デバッグプロキシアプリケーションです。他にも用途がいくつかあります。提供されているバージョンは、Windows、OS X および Linux です。

最適化ツール

監視

パフォーマンスの監視では、問題の診断と調整すべき領域の特定に役立つツールと方法について説明しています。

タッチ UI の開発者モード

AEM 6 のタッチ操作向け UI の新機能の 1 つに、開発者モードがあります。作成者が編集モードとプレビューモードを切り替えられるのと同じように、開発者はオーサー UI で開発者モードに切り替えて、ページ上の各コンポーネントのレンダリング時間の確認と、エラーのスタックトレースの確認ができます。開発者モードについて詳しくは、こちらの CQ Gems のプレゼンテーションを参照してください。

rlog.jar を使用したリクエストログの解読

AEM システムのリクエストログをより包括的に分析するには、rlog.jar を使用して、AEM で生成される request.log の検索および並べ替えをおこなうことができます。この jar ファイルは、AEM のインストールフォルダーの /crx-quickstart/opt/helpers に含まれています。rlog ツールとリクエストログ全般について詳しくは、監視と保守に関するドキュメントの参照してください。

クエリーの説明を実行ツール

ACS AEM ツールのクエリの説明を実行ツールを使用して、クエリ実行時に使用されるインデックスを表示できます。これは低速なクエリの実行を最適化する場合に非常に便利です。

PageSpeed ツール

Google の PageSpeed ツールは、ページパフォーマンスに関するベストプラクティスを実践するためのサイト分析や、さらなる最適化のために Apache インスタンスに Dispatcher と共にインストールできるプラグインを提供します。詳しくは、PageSpeed ツールの Web サイトを参照してください。

 

オーサー環境

テストの実行

オーサー環境でパフォーマンステストを実行するには、実稼動環境のオーサーインスタンスのエクスペリエンスをシミュレートしなければなりません。つまり、オーサーインスタンスの環境に、コンポーネント、OSGi バンドル、UI カスタマイズ、カスタムインデックスなど、実稼動環境のオーサーインスタンスに配置される様々な追加要素をすべて含めておく必要があります。

パフォーマンステストや負荷テスト用に設計された自動化フレームワークは数多くあります。これらのツールでカスタムのスクリプトを記録して再生することで、同様のコンテンツの作成とアクティベートアクティビティを同時に実行するピーク時のオーサーインスタンスの数をシミュレートすることが可能です。Tough Day ツールを使用し、数千個のアセットのアップロードや多数のページのアクティベートなどのアクティビティをシミュレートすることを推奨します。

高負荷のアセット読み込みやページオーサリングが必要になるような環境では、Tough Day のようなツールを使用して、ピーク時の負荷でも環境が効率的に動作するかを確認することが必要です。WebDAV はスクリプトを必要としないツールで、大量のアセットを読み込むためにも使用できます。

MongoDB 固有の手順

バックエンドに MongoDB を使用しているシステムでは、負荷テストまたはパフォーマンステスト時に AEM の以下の JMX MBean を監視する必要があります。

  • 統合キャッシュ統計 MBean。http://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D6%2Cname%3D%22Consolidated+ Cache+statistics%22%2Ctype%3D%22ConsolidatedCacheStats%22 に移動すると直接アクセスできます。

Document-Diff という名前のキャッシュは、ヒット率を .90 以上にする必要があります。ヒット率が 90 %を下回る場合は、DocumentNodeStoreService の設定を変更しなければならない可能性があります。お使いの環境に最適な設定はアドビの製品サポートからご案内できます。

  • Oak リポジトリ統計 Mbean。http://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D16%2Cname%3D%22Oak+ Repository+Statistics%22%2Ctype%3D%22RepositoryStats%22 に移動すると直接アクセスできます。

ObservationQueueMaxLength のセクションには、直前の数時間、数分、数秒、数週間の Oak の観測キュー内のイベント数が表示されます。「per hour」のセクションでイベントの最大数を確認します。この数値を、OSGi コンソールSlingRepositoryManager コンポーネントで確認できるoak.observation.queue-length の設定と比較する必要があります。観測キューで表示される最大数が queue-length の設定を上回る場合は、設定の引き上げに関してアドビのサポートまでお問い合わせください。初期設定は 1,000 ですが、ほとんどの環境では、通常は 20,000 または 50,000 まで引き上げる必要があります。

パブリッシュ環境

テストの実行

負荷テストの対象となるデプロイメントで最も重要なのは、エンドユーザーに対面するパブリッシュ環境または Dispatcher 環境です。

このような Web サイトのパフォーマンスは、サードパーティの自動テストツールを使用してテストできます。こうしたツールを使用すると、ユーザーがサイト上でおこなう手順を記録したうえで、その手順を同時にいくつも実行し、実稼動 Web サイトと同様の負荷をシミュレートできます。

ほとんどの実稼動 Web サイトでは、Dispatcher キャッシュやコンテンツ配信ネットワークなどの最適化機能が導入されています。テスト時は、こうした最適化機能がテスト環境でも利用できるどうかを確認する必要があります。エンドユーザーの応答時間の監視に加えて、システムがハードウェアリソースによる制約を受けていないことを確認するために、パブリッシュサーバーと Dispatcher のシステム指標を監視する必要があります。

高度なパーソナライゼーションを必要としないシステムでは、Dispatcher がほとんどのリクエストをキャッシュする必要があります。これにより、パブリッシュインスタンスの負荷を比較的一定に保つことができます。高度なパーソナライゼーションが必要な場合は、可能な限り Dispatcher キャッシュを利用できるよう、パーソナライズされたコンテンツに iFrames や AJAX リクエストなどのテクノロジーを使用することを推奨します。

基本的なテストの場合は、Apache Bench を使用して Web サーバーの応答時間を測定し、メモリリークなどの問題を測定するための負荷を生成できます。詳しくは、監視に関するドキュメントの例を参照してください。

パフォーマンス問題のトラブルシューティング

オーサーインスタンスでパフォーマンステストを実行した後に、問題が発生した場合は、調査、診断および対応をおこなう必要があります。問題の分析と対応をおこなう際には、いくつかのツールと手法を使用できます。

  • 操作ダッシュボードで要求パフォーマンスログを確認できます。このツールを使用して低速なページリクエストを特定できます。
  • クエリパフォーマンスツールで実行が遅いクエリを分析します。
  • エラーログを見てエラーや警告を調べます。詳しくは、ログを参照してください。
  • メモリや CPU の使用状況のなどシステムのハードウェアリソースを監視します。これらのリソースが、パフォーマンスボトルネックの原因になっていることがよくあります。
  • キャッシュを最大限に確保するために、ページのアーキテクチャと、URL パラメーターの使用を最小限に抑えるための仕組みを最適化します。
  • パフォーマンスの最適化Performance tuning tips のドキュメントに従ってください。
  • オーサーインスタンスでの特定のページやコンポーネントの編集に問題がある場合は、タッチ UI の開発者モードを使用して、問題のあるページを調べてください。そうすることで、ページ上の各コンテンツ領域の内訳とそれぞれの読み込み時間がわかります。
  • サイト上のすべての JS と CSS を最小限にします。具体的な方法については、こちらのブログ投稿を参照してください。
  • コンポーネントに埋め込まれた CSS と JS を削除します。ページのレンダリングに必要な要求の数を最小限にするには、これらをクライアント側のライブラリに組み込んで最小化する必要があります。
  • Chrome の「ネットワーク」タブなどのツールを使用してサーバーリクエストを調べることで、最も時間がかかるコンポーネントを確認します。

問題の領域を特定したら、パフォーマンスの最適化のためにアプリケーションコードを調べます。AEM の機能で適切に動作しないものがある場合は、アドビのサポートまで問い合わせてください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー