チェック項目 | 検討事項 | 注釈/アクション |
---|---|---|
バックアップ計画 | CQ インスタンスのバックアップ方法を参照してください。 | |
障害回復計画 | 各社の障害回復ガイドライン。 | |
問題を報告するためのエラー追跡システムが利用可能であること | 例えば、bugzilla、jira、その他多数のうちいずれか。 | |
ファイルシステムが監視されていること | ディスクの空き容量が不十分な場合、CRX リポジトリは「フリーズ」します。容量が利用可能になると再開します。 | 空き容量が少なくなると、「*ERROR* LowDiskSpaceBlocker」メッセージがログファイルに記録されます。 |
ログファイルが監視されていること | ||
システム監視がバックグラウンドで(一貫して)実行されていること | CPU、メモリ、ディスクおよびネットワークの使用状況を含みます。例えば、iostat、vmstat、perfmon を使用します。 | ログに記録されたデータを可視化して、パフォーマンス問題の追跡に使用できます。生のデータにもアクセスできます。 |
CQ パフォーマンスが監視されていること | トラフィックレベルを監視する要求カウンターを含みます。 | 重大な、または長期にわたるパフォーマンスの損失が見られる場合は、詳細な調査をする必要があります。 |
レプリケーションエージェントを監視していること | ||
ワークフローインスタンスを定期的にパージすること | リポジトリのサイズとワークフローのパフォーマンス。 | ワークフローインスタンスの定期的なパージを参照してください。 |
企業で決められているバックアップポリシーがある場合は、それに従う必要があります。何をいつバックアップするかについては、次の点も考慮してください。
- システムおよびデータの重要度。
- ソフトウェアまたはデータの変更の頻度。
- データのボリューム。バックアップの実施に必要な時間と同様に、容量も問題になる場合があります。
- ユーザーがオンライン中にバックアップを実施できるかどうか。可能な場合は、パフォーマンスへの影響。
- ユーザーの地理的分布。つまり、バックアップに最適な(影響が最小限に抑えられる)時間帯。
- 障害回復ポリシー。バックアップデータの格納場所(オフサイト、特定のメディア、など)に関するガイドラインがあるかどうか。
一般的には、完全バックアップを一定の間隔(例:1 日ごと、週ごと、月ごと)でおこない、その合間に増分バックアップをおこないます(例:1 時間ごと、1 日ごと、週ごと)。
警告:
実稼動インスタンスのバックアップを実装するときは、バックアップを正常に復元できることを確認するために、テストをおこなう必要があります。
そうしないと、最悪の場合、バックアップが無駄になる可能性があります。
注意:
バックアップのパフォーマンスについて詳しくは、バックアップのパフォーマンスを参照してください。
これをおこなうには、リポジトリ全体をバックアップする必要があります。その後、以下の手順を実行します。
警告:
クラスターを操作している場合は、「共有」フォルダーが別の場所にある場合があり、これもバックアップが必要です。クラスターの設定について詳しくは、CQ でのクラスターの設定を参照してください。
警告:
サードパーティのアプリケーションサーバーを操作している場合は、追加のフォルダーが別の場所にある場合があり、これらもバックアップが必要なことがあります。アプリケーションサーバーのインストールについて詳しくは、CQ5 をアプリケーションサーバーと共にインストールする方法を参照してください。
警告:
ファイルデータストアの増分バックアップがサポートされています。その他のコンポーネント(Lucene インデックスなど)の増分バックアップを使用する場合は、削除済みのファイルがバックアップでも削除済みとマークされることを確認してください。
注意:
ディスクミラーリングも、バックアップメカニズムとして使用できます。
CRX ドキュメントのバックアップと復元に、CRX リポジトリのバックアップに関連するすべての問題が掲載されています。
オンラインの「ホット」バックアップの作成について詳しくは、オンラインバックアップの作成を参照してください。
ここでは、CQ のバージョン管理機能に関連する保守操作について説明します。バージョンのパージツールは、リポジトリ内のノードまたはノードの階層のバージョンを削除します。このツールの主な目的は、古いバージョンのノードを削除して、リポジトリのサイズを削減することです。
バージョンのパージツールは、ツールコンソールの「バージョン管理」の下か、次の場所にあります。
http://<server>:<port>/etc/versioning/purge.html

ドライラン
コンテンツのバージョンの削除は取り消しできず、元に戻すにはバックアップを復元するしかないので、バージョンのパージツールでは、パージ対象のバージョンをプレビューできるドライランモードが提供されています。パージ処理のドライランを開始するには、「ドライラン」をクリックします。
-
ツールコンソールに移動して、「バージョン管理」を選択し、「バージョンのパージ」をダブルクリックします。
警告:
パージされたノードを元に戻すには、リポジトリを復元するしかありません。設定は自己管理する必要があるので、パージの前に必ずドライランを実行することをお勧めします。
「ドライラン」と「パージ」の処理では、処理されたすべてのノードがリストされます。処理の間、ノードのステータスは次のうちいずれかになります。
- ignore (not versionnable):ノードはバージョン管理をサポートしないので、処理中は無視されます。
- ignore (no version):ノードにバージョンが含まれていないので、処理中は無視されます。
- retained:ノードはパージされません。
- purged:ノードはパージされます。
さらに、コンソールでは、バージョンに関して次のような有益な情報が提供されます。
- V 1.0:バージョン番号。
- V 1.0.1*:星マークは、バージョンが最新であることを示します。
- Thu Mar 15 2012 08:37:32 GMT+0100:バージョンの日付。
例を以下に示します。
- Shirts のバージョンは、バージョンの期間が 2 日間を超えているので、パージされます。
- Tonga Fashions! のバージョンは、バージョンの数が 5 を超えているので、パージされます。

AEM WCM では詳細なログを記録します。クイックスタートを解凍して起動すると、次の場所にログが見つかります。
- <cq-installation-dir>/crx-quickstart/logs/
- <cq-installation-dir>/crx-quickstart/repository/
ログファイルのローテーションとは、定期的に新しいファイルを作成することによってファイルサイズの拡大を制限するプロセスのことです。AEM では、error.log というログファイルが、指定したルールに従って 1 日 1 回ローテーションされます。
- error.log ファイルは、{original_filename}.yyyy-MM-dd というパターンで名前変更されます。例えば、2010 年 7 月 11 日には、最新のログファイルの名前が error.log-2010-07-10 に変更され、その後新しい error.log が作成されます。
- 以前のログファイルは削除されないので、自己責任で古いログファイルを定期的にクリーンアップして、ディスクの使用量を制限してください。
注意:
AEM をアップグレードする場合は、AEM でこれ以上使用されない既存のログファイルがディスク上に残ることに注意してください。これらは削除しても問題ありません。新しいログエントリはすべて、新しいログファイルに書き込まれます。
- <cq-installation-dir>/crx-quickstart/logs
- access.log
AEM WCM およびリポジトリに対するアクセス要求はすべてここに登録されます。 - audit.log
モデレートアクションはここに登録されます。 - error.log
エラーメッセージ(様々な深刻度レベル)はここに登録されます。 - ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
このログは、ダイナミックメディアが有効な場合にのみ使用されます。内部 Image Server プロセスの動作の分析に使用する、統計および分析情報を提供します。 - request.log
各アクセス要求が、応答と共にここに登録されます。 - s7access-<yyyy>-<mm>-<dd>.log
このログは、ダイナミックメディアが有効な場合にのみ使用されます。s7access ログは、/is/image および /is/content 経由でダイナミックメディアに対しておこなわれた要求を記録します。 - stderr.log
起動時に生成されたエラーメッセージ(様々な深刻度レベル)を保持します。デフォルトでは、ログレベルは Warning(WARN)に設定されています。 - stdout.log
起動時のイベントを示すログメッセージを保持します。 - upgrade.log
com.day.compat.codeupgrade パッケージおよび com.adobe.cq.upgradesexecutor パッケージから実行されるすべてのアップグレード操作のログを提供します。
- access.log
- <cq-installation-dir>/crx-quickstart/repository
- revision.log
リビジョンジャーナル処理の情報。
- revision.log
注意:
Image Server および s7access のログは、system/console/status-Bundlelist ページから生成される「すべてダウンロード」パッケージには含まれません。サポート目的で、ダイナミックメディアの問題がある場合は、カスタマーサポートに連絡する際に Image Server と s7access のログも添付してください。
デフォルトのログレベル(Apache Sling Logging Configuration)は情報(INFO)なので、デバッグメッセージはログに記録されません。
ロガーのデバッグログレベルをアクティベートするには、リポジトリで org.apache.sling.commons.log.level プロパティを debug に設定します。例えば、/libs/sling/config/org.apache.sling.commons.log.LogManager で、グローバル Apache Sling Logging を設定します。
警告:
デバッグログレベルのログを、不必要に長く残さないでください。多くのログエントリが生成され、リソースが消費されます。
DEBUG 3 WebApp Panel:WebApp successfully deployed
0 | 重大なエラー | アクションが失敗し、インストーラーの処理を続行できません。 |
1 | エラー | アクションが失敗しました。インストールは続行しますが、AEM WCM の一部が正常にインストールされなかったので、機能しません。 |
2 | 警告 | アクションは成功しましたが、問題が発生しました。AEM WCM が正常に機能するかどうかは不明です。 |
3 | 情報 | アクションが成功しました。 |
注意:
Adobe Experience Manager を操作しているときは、このようなサービスの設定を管理する方法がいくつかあります。詳細および推奨事項については、OSGi の設定を参照してください。
-
/apps/<project-name>/config の下に、新しい Apache Sling Logging Logger Configuration 用のノードを作成します。
- 名前:org.apache.sling.commons.log.LogManager.factory.config-<identifier>(これはロガーなので)
<identifier> の部分は、インスタンスを識別するために入力するフリーテキストに置き換えます(この情報は省略できません)。例えば、org.apache.sling.commons.log.LogManager.factory.config-MINE とします。 - タイプ:sling:OsgiConfig
注意:
技術的に必須ではありませんが、<identifier> は一意にすることをお勧めします。
- 名前:org.apache.sling.commons.log.LogManager.factory.config-<identifier>(これはロガーなので)
-
このノードで次のプロパティを設定します。
- 名前:org.apache.sling.commons.log.file
タイプ:String
値:ログファイルを指定します。例えば、logs/myLogFile.log とします。
- 名前:org.apache.sling.commons.log.names
タイプ:String[](String + Multi)
値:ロガーによってメッセージをログに記録する OSGi サービスを指定します。例えば、以下すべてを指定します。- org.apache.sling
- org.apache.felix
- com.day
- 名前:org.apache.sling.commons.log.level
タイプ:String
値:必要なログレベル(debug、info、warn または error)を指定します。例えば、debug を指定します。 - 必要に応じてその他のパラメーターを設定します。
- 名前:org.apache.sling.commons.log.pattern
タイプ:String
値:必要に応じてログメッセージのパターンを指定します。次に例を示します。
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
- 名前:org.apache.sling.commons.log.pattern
注意:
org.apache.sling.commons.log.pattern では、最大 6 個の引数がサポートされています。
{0} タイプが java.util.Date のタイムスタンプ
{1} ログマーカー
{2} 現在のスレッドの名前
{3} ロガーの名前
{4} ログレベル
{5} ログメッセージログ呼び出しに Throwable が含まれている場合は、スタックトレースがメッセージに付加されます。
警告:
org.apache.sling.commons.log.names には値が必要です。
注意:
ログライターのパスは、crx-quickstart の場所と相対的です。
したがって、ログファイルが
logs/thelog.log
と指定されている場合、書き込み先は以下となります。
<cq-installation-dir>/crx-quickstart/logs/thelog.log.
また、ログファイルが
../logs/thelog.log
と指定されている場合、書き込み先は以下のディレクトリとなります。
<cq-installation-dir>/logs/
(<cq-installation-dir>/crx-quickstart/ の隣り) - 名前:org.apache.sling.commons.log.file
-
警告:
新しい Logging Writer Configuration は、既存のデフォルトが適切でない場合にのみ必要です。
明示的なライターが設定されていない場合は、デフォルトに基づいて暗黙のライターが自動的に生成されます。
/apps/<project-name>/config の下に、新しい Apache Sling Logging Writer Configuration 用のノードを作成します。
- 名前:org.apache.sling.commons.log.LogManager.factory.writer-<identifier>(これはライターなので)
ロガーと同様に、<identifier> は、インスタンスを識別するために入力するフリーテキストに置き換えます(この情報は省略できません)。例えば、org.apache.sling.commons.log.LogManager.factory.writer-MINE とします。 - タイプ:sling:OsgiConfig
注意:
技術的に必須ではありませんが、<identifier> は一意にすることをお勧めします。
このノードで次のプロパティを設定します。
- 名前:org.apache.sling.commons.log.file
タイプ:String
値:ロガーで指定されているファイルと一致するように、ログファイルを指定します。
ここでは、../logs/myLogFile.log と指定します。 - 必要に応じてその他のパラメーターを設定します。
- 名前:org.apache.sling.commons.log.file.number
タイプ:Long
値:保持するログファイルの数を指定します。例えば、5 とします。 - 名前:org.apache.sling.commons.log.file.size
タイプ:String
値:ファイルのローテーションをサイズや日付によって制御するために、必要に応じて指定します。例えば、'.'yyyy-MM-dd とします。
- 名前:org.apache.sling.commons.log.file.number
注意:
org.apache.sling.commons.log.file.size は、次のいずれかを設定することによって、ログファイルのローテーションを制御します。
- 最大ファイルサイズ
- 時刻/日付のスケジュール
これにより、新しいファイルを作成する(また、名前のパターンに従って既存のファイルを名前変更する)条件を示します。
- サイズ制限は数値で指定できます。サイズの単位を指定しない場合は、バイト数と見なされます。また、サイズの単位として KB、MB または GB(大文字小文字の区別なし)を追加することもできます。
- 時刻/日付のスケジュールは、java.util.SimpleDateFormat のパターンとして指定できます。これは、どのくらいの期間を経過したらファイルをローテーションするかを定義します。また、ローテーション後のファイルには識別のためにサフィックスが付加されます。
デフォルトは '.'yyyy-MM-dd(1 日ごとにログをローテーション)です。
したがって、例えば、2010 年の 1 月 20 日の深夜 12 時(またはこの後の最初のログメッセージが時間ちょうどに発生した場合)に、../logs/error.log は ../logs/error.log.2010-01-20 に名前変更されます。1 月 21 日のログは、(新しい空の)../logs/error.log に出力され、次の日付の変わり目にロールオーバーされます。'.'yyyy-MM 毎月の初めにローテーション。 '.'yyyy-ww 毎週最初の日(ロケールによって異なる)にローテーション。 '.'yyyy-MM-dd 毎日深夜 12 時にローテーション。 '.'yyyy-MM-dd-a 毎日深夜 12 時および正午にローテーション。 '.'yyyy-MM-dd-HH 毎正時にローテーション。 '.'yyyy-MM-dd-HH-mm 毎分の初めにローテーション。
1. 文字テキストは、単一引用符(' ')で囲んで「エスケープ」する必要があります。
これは、一定の文字がパターン文字として解釈されるのを防ぐためです。
2. オプションのどの場所でも、有効なファイル名に許可されている文字のみを使用してください。
- 名前:org.apache.sling.commons.log.LogManager.factory.writer-<identifier>(これはライターなので)
Felix コンソールでは、../system/console/slinglog の Sling Log Support に関する情報も提供されます。例えば、http://localhost:4502/system/console/slinglog です。
/var/audit フォルダー内では、監査記録はリソースに従って保持されます。ドリルダウンすると、個々の記録およびそれぞれに含まれる情報を確認できます。
これらのエントリに保持されている情報は、ページ編集時に表示される情報と同じです。

レプリケーションキューを監視すると、キューのダウンまたはブロックを検出できます。このような場合、パブリッシュインスタンスまたは外部システムに問題がある可能性があります。
- 必要なキューがすべて有効になっていますか。
- 無効なキューの中に、まだ必要なものがありますか。
- enabled(有効な状態)のキューはすべて、ステータスが idle または active であり、これは正常な動作を示します。キューを blocked(ブロック状態)にしてはいけません。ブロックされている場合、多くは受信者側に問題があります。
- 時間の経過と共にキューのサイズが大きくなる場合は、キューがブロックされている可能性があります。
-
ここでは、以下のことができます。
- エージェントが有効かどうかを確認。
- レプリケーションのターゲットを確認。
- レプリケーションキューが現在アクティブ(有効)かどうかを確認。
- キュー内に項目が含まれているかどうかを確認。
- 更新または消去して、キューエントリの表示を更新。これは、キューに出入りする項目の確認に役立ちます。
- ログを表示して、レプリケーションエージェントによるアクションのログにアクセス。
- ターゲットインスタンスへの接続をテスト。
- 必要に応じて、任意のキュー項目で強制的に再試行。
警告:
パブリッシュインスタンスのリバースレプリケーションアウトボックスには、「接続をテスト」リンクは使用しないでください。
アウトボックスクエリー用にレプリケーションテストが実行されると、リバースレプリケーションのたびに、テストレプリケーションより古い項目がすべて再処理されます。
そのような項目がキュー内に既に存在する場合は、次の XPath JCR クエリーを使用して検索し、削除する必要があります。
/jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']
ここでも、すべてのレプリケーションエージェント(/etc/replication/author または /etc/replication/publish の下)を検出して、エージェントのステータス(enabled、disabled)および基になるキューのステータス(active、idle、blocked)を確認するソリューションを開発できます。
パフォーマンスの最適化は、開発時に注目を集めるインタラクティブなプロセスです。デプロイメント後、通常は特定の間隔またはイベントの後でレビューされます。
最適化のための情報収集に使用する方法は、継続中の監視にも使用できます。
注意:
具体的なパフォーマンス向上のための設定も確認できます。
領域 | 現象 | 容量を増やす方法 | ボリュームを減らす方法 |
クライアント | クライアントの CPU 使用率が高い。 | より高性能のクライアント CPU をインストール。 | (HTML)レイアウトを簡素化。 |
サーバーの CPU 使用率が低い。 | より高速なブラウザーにアップグレード。 | クライアント側のキャッシュを改善。 | |
高速のクライアントと低速のクライアントがある。 | |||
サーバー | |||
ネットワーク | サーバーとクライアントの両方で CPU 使用率が低い。 | ネットワークのボトルネックを除去。 | クライアントキャッシュの設定を改善/最適化。 |
サーバーのローカルでの参照が(比較的)高速。 | ネットワーク帯域幅を増加。 | Web ページの「重さ」を軽減(例:画像を減らす、HTML を最適化する)。 | |
Web サーバー | Web サーバー上の CPU 使用率が高い。 | Web サーバーをクラスター化。 | ページごとのヒット数(訪問数)を減らす。 |
ハードウェアのロードバランサーを使用。 | |||
アプリケーション | サーバーの CPU 使用率が高い。 | CQ5 インスタンスをクラスター化。 | CPU およびメモリが集中的に使用されている箇所を検索して除去(コードレビュー、タイミング出力などを使用)。 |
メモリ消費率が高い。 | すべてのレベルでキャッシュを改善。 | ||
応答時間が遅い。 | テンプレートおよびコンポーネント(構造、ロジックなど)を最適化。 | ||
リポジトリ | |||
キャッシュ |
- パフォーマンス問題が発生する前の対応:
- できる限り多くの情報を収集し、正常な状態のシステムに関する十分な実用的知識を構築します。
- パフォーマンス問題が発生した場合の対応:
- 1 つ(または 2 つ以上を推奨)の標準的な Web ブラウザー、通常のパフォーマンスが良好であることがわかっている別のクライアント、またはサーバー自体(可能であれば)で、問題を再現します。
- 適切な時間内に(システムに関連する)何かが変更されたかどうかと、いずれかの変更がパフォーマンスに影響した可能性があるかどうかを確認します。
- 次の点を確認します。
- 問題が発生するのは特定の時間のみかどうか。
- 問題が発生するのは特定のページのみかどうか。
- その他の要求に影響があるかどうか。
- できる限り多くの情報を収集し、正常な状態のシステムに関する知識と比較します。
ツール | 分析対象 | 使用法/詳細 |
request.log | 応答時間および並行性 | request.log の解釈。 |
truss/strace | ページの読み込み | システムの呼び出しおよびシグナルをトレースする Unix/Linux コマンド。ログレベルを INFO に上げます。 要求ごとのページの読み込み数、どのページか、などを分析します。 |
スレッドダンプ | JVM スレッドを監視。競合、ロック、長時間の実行を識別。 | オペレーティングシステムによって異なります。 TDA などの分析ツールも使用できます。 |
ヒープダンプ | パフォーマンス低下の原因となるメモリ不足の問題。 | CQ に対する java 呼び出しに、 Troubleshooting Guide for Java SE 6 with HotSpot VM を参照してください。 |
システム呼び出し | タイミングの問題を識別。 | System.currentTimeMillis() または com.day.util に対する呼び出し。タイミングは、コードから、または HTML コメント経由でタイムスタンプを生成するために使用します。 注意: これらを実装するのは、必要に応じてアクティベート/アクティベート解除できるようにするためです。システムが問題なく動作しているときは、統計を収集するオーバーヘッドは不要です。 |
Apache Bench | メモリリークを識別し、応答時間を選択分析。 | 基本的な使用法は次のとおりです。 ab -k -n <requests> -c <concurrency> <url> 詳しくは、Apache Bench および ab マニュアルページを参照してください。 |
Search Analysis | 検索クエリーをオフラインで実行し、クエリーの応答時間を特定して、結果セットをテストおよび確認します。 |
|
JMeter | 読み込みおよび機能テスト。 | http://jakarta.apache.org/jmeter/ |
JProfiler | CPU およびメモリの詳細なプロファイリング。 | http://www.ej-technologies.com/ |
JConsole | JVM の指標およびスレッドを監視。 | 使用法:jconsole jconsole および JConsole を使用したパフォーマンスの監視 を参照してください。 注意: JDK 1.6 では、Top や TDA(Thread Dump Analyzer)などのプラグインを使用して JConsole を拡張できます。 |
Java VisualVM | JVM の指標、スレッド、メモリおよびプロファイリングを監視。 | 使用法:jvisualvm または visualvm jvisualvm、visualvm および(J)VisualVM を使用したパフォーマンスの監視を参照してください。 注意: JDK 1.6 では、プラグインを使用して VisualVM を拡張できます。 |
truss/strace、lsof | 詳細なカーネル呼び出しおよびプロセス分析(Unix)。 | Unix/Linux コマンド。 |
タイミングの統計 | ページレンダリングのタイミングの統計を確認。 | ページレンダリングのタイミングの統計を確認するには、Ctrl+Shift+U を、URL で設定されている ?debugClientLibs=true と共に使用します。 |
CPU およびメモリプロファイリングツール |
開発中に低速の要求を分析する際に使用。 | 例えば、YourKit などです。 |
情報収集 | インストールの進行中のステータス。 | インストールについてできる限り知っておくことは、パフォーマンスの変化の原因や、変化が正当かどうかを追跡する上でも役立ちます。これらの指標を一定の間隔で収集し、重大な変化を簡単に確認できるようにする必要があります。 |
request.log は、要求の所要時間を確認する方法として組み込まれています。開発目的では、request.log の末尾に -f を付けて、応答時間が遅くなる現象を監視すると便利です。サイズの大きい request.log を分析するには、rlog.jar を使用して、応答時間を分類してフィルター処理することをお勧めします。
「低速の」ページを request.log から分離し、個々に調整してパフォーマンスを向上させることをお勧めします。そのためには、通常はコンポーネントごとにパフォーマンス指標を含めるか、yourkit などのパフォーマンスプロファイリングツールを使用します。
09:43:41 [66] -> GET /author/y.html HTTP/1.1 09:43:41 [66] <- 200 text/html 797ms
パフォーマンス分析は、request.log から始めることをお勧めします。
<cq-installation-dir>/crx-quickstart/logs/request.log
ログは次のようになっています(簡潔にするために、各行を短縮しています)。
31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1 31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms 31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1 31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms
このログには、要求または応答ごとに 1 行ずつの構成になっています。
- 要求または応答がおこなわれた日付。
- 要求の番号(角括弧内)。この番号は、要求と応答で一致しています。
- 矢印は、要求(右向き矢印)か応答(左向き矢印)かを示しています。
- 要求の行には、以下が含まれます。
- メソッド(通常は GET、HEAD または POST)
- 要求されたページ
- プロトコル
- 応答の行には、以下が含まれます。
- ステータスコード(200 は「成功」、404 は「ページが見つかりません」)
- MIME タイプ
- 応答時間
サイズの小さいスクリプトを使用して、ログファイルから必要な情報を抽出し、必要な統計を取ることができます。これらの統計から、どのページ、またはどんなタイプのページが低速か、全体的なパフォーマンスが十分かどうかを確認できます。
31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1 31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms
ここでも、request.log を使用して、並行性およびそれに対するシステムの反応を監視できます。
テストを実施して、悪影響なくシステムが処理できる同時ユーザーの数を特定する必要があります。ここでも、スクリプトを使用してログファイルから結果を抽出できます。
- 特定の期間(1 分間など)内におこなわれる要求の数を監視します。
- 特定の数のユーザー全員がほぼ同時に同じ要求をおこなった場合の影響をテストします(例えば、30 人のユーザーが同時に「保存」をクリックするなど)。
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1 31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1 31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1 31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms 31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms 31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms 31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1 31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1 31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms 31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms
CQ には、様々なヘルパーツールが以下の場所に含まれています。
<cq-installation-dir>/crx-quickstart/opt/helpers
その 1 つ、rlog.jar を使用すると、request.log を短時間で分類し、所要時間を基準として、最長から最短の順序で要求を表示できます。
次のコマンドは、考えられる引数を示しています。
$java -jar rlog.jar Request Log Analyzer Version 21584 Copyright 2005 Day Management AG Usage: java -jar rlog.jar [options] <filename> Options: -h Prints this usage. -n <maxResults> Limits output to <maxResults> lines. -m <maxRequests> Limits input to <maxRequest> requests. -xdev Exclude POST request to CRXDE.
$ java -jar ../opt/helpers/rlog.jar -n 10 request.log *Info * Parsed 464 requests. *Info * Time for parsing: 22ms *Info * Time for sorting: 2ms *Info * Total Memory: 1mb *Info * Free Memory: 1mb *Info * Used Memory: 0mb ------------------------------------------------------ 18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html 2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript 1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html 1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html 1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript 1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript 1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript 1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8 1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json 1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
特殊なケース(ガベージコレクションなど)の影響を最小限にするために、apachebench(詳細なドキュメントについては ab などを参照)などのツールを使用してメモリリークを特定し、応答時間を選択分析することをお勧めします。
Apache Bench は次の方法で使用できます。
$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html" This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Day-Servlet-Engine/4.1.52 Server Hostname: localhost Server Port: 4503 Document Path: /content/geometrixx/en/company.html Document Length: 24127 bytes Concurrency Level: 5 Time taken for tests: 69.766 seconds Complete requests: 1000 Failed requests: 998 (Connect: 0, Receive: 0, Length: 998, Exceptions: 0) Write errors: 0 Keep-Alive requests: 0 Total transferred: 24160923 bytes HTML transferred: 24010923 bytes Requests per second: 14.33 /sec (mean) Time per request: 348.828 [ms] (mean) Time per request: 69.766 [ms] (mean, across all concurrent requests) Transfer rate: 338.20 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 3.9 0 58 Processing: 138 347 568.5 282 8106 Waiting: 137 344 568.1 281 8106 Total: 139 348 568.4 283 8106 Percentage of the requests served within a certain time (ms) 50% 283 66% 323 75% 356 80% 374 90% 439 95% 512 98% 1047 99% 1132 100% 8106 (longest request)
上記の数値は、標準的な MAcBook Pro ラップトップ(2010 年半ば)から、CQ 5.6.1 のデフォルトインストールに含まれている Geometrixx 社のページにアクセスして得られたものです。このページは非常にシンプルですが、パフォーマンス向けに最適化はされていません。
apachebench では、同時に実行されているすべての要求の、要求ごとの所要時間の平均も表示されます。Time per request: 54.595 [ms] (mean, across all concurrent requests) を参照してください。並列性のパラメーター -c(同時に実行する複数の要求の数)の値を変更すると、それによる影響の有無を確認できます。
要求トラフィックに関する情報(特定の期間の要求数)により、インスタンスの負荷の目安がわかります。この情報は request.log から抽出できますが、カウンターを使用すると、データ収集を自動化し、以下の情報を確認できます。
- アクティビティの大きな相違点(「多数の要求」と「少ないアクティビティ」を区別)
- インスタンスが使用されていない時間帯
- 再起動(カウンターが 0 にリセット)があるかどうか
情報収集を自動化するには、RequestFilter をインストールして、要求がおこなわれるたびにカウンターの数値を増やすこともできます。複数のカウンターを様々な期間に使用できます。
収集された情報を使用して、以下の内容を示すことができます。
- アクティビティの大きな変化
- 冗長なインスタンス
- 再起動(カウンターが 0 にリセット)があるかどうか
サーバーのパフォーマンスを向上するために、プロジェクトごとに html comments を含めることをお勧めします。良い例が多数公開されています。ページを選択し、ページソースを開いて下までスクロールすると、次のようなコードを確認できます。
</body> </html> <!-- Page took 58 milliseconds to be rendered by server -->
-
次のいずれかを実行します。
- jvisualvm:JDK 1.6 bin フォルダー内(テスト済みバージョン)
- visualvm:VisualVM からダウンロードできます(最先端バージョン)
インストールについてできる限り知っておくことは、パフォーマンスの変化の原因や、変化が正当かどうかを追跡する上で役立ちます。これらの指標を一定の間隔で収集し、重大な変化を簡単に確認できるようにする必要があります。
有益な情報を以下に示します。
cd <cq-installation-dir>/crx-quickstart/logs cut -d " " -f 3 access.log | sort -u | wc -l
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l
サーバーのインストール以降のページアクティベーションの合計数を確認するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー //element(*, cq:AuditEvent)[@cq:type='Activate']
現在サーバー上にあるページの数を確認するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー //element(*, cq:Page)
インストール以降のロールアウトの合計数を特定するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
インストール以降におこなわれたライブコピーの合計数を特定するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー //element(*, cq:LiveSyncConfig)
現在保守している DAM アセットの数を確認するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー /jcr:root/content/dam//element(*, dam:Asset)
現在サーバー上にあるテンプレートの数を確認するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー //element(*, cq:Template)
現在サーバー上にあるコンポーネントの数を確認するには、リポジトリクエリーを使用します。CRXDE のツール/クエリーで、次のように指定します。
- タイプ XPath
- Path /
- クエリー //element(*, cq:Component)
システムがディスク容量不足になっている場合や、ディスクスラッシングが始まっていることに気付いた場合は、以下を参照してください。
- Tar ファイルの最適化およびクラスターでの Tar ファイルの最適化
- デバッグ情報のコレクションを無効にしているかどうか。これは、以下を含む様々な場所で設定できます。
- バージョンのパージを設定しているかどうかと、その設定方法
- ナレッジベース
リブートのたびにインスタンスのパフォーマンスの低下が確認される場合(場合によって 1 週間後またはそれ以降)は、以下を確認できます。
- メモリ不足
- ナレッジベース
Java 仮想マシン(JVM)のチューニング機能は大幅に改善されています(特に Java 7 以降)。したがって、ある程度の固定の JVM サイズを指定し、デフォルトを使用すれば、たいていの場合に対応できます。
デフォルト設定が適切でない場合は、GC パフォーマンスを監視および査定する方法を確立してから JVM のチューニングを試みることが重要です。これには、ヒープサイズ、アルゴリズム、その他の局面を含む要因の監視が必要になる場合があります。
一般的な選択肢は以下のとおりです。
- VerboseGC:
-verbose:gc \
-Xloggc:$LOGS/verbosegc.log \
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps
結果のログは、次のような GC 可視化機能によって取り込み可能です。
http://www.ibm.com/developerworks/library/j-ibmtools2/
JConsole の場合は以下のとおりです。
- 以下の設定は、「広く開放された」JMX 接続用です。
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8889 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false - 次に、JConsole を使用して JVM に接続します。以下を参照してください。
http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
これは、使用中のメモリ量、使用されている GC アルゴリズム、アルゴリズムの実行にかかる時間、アプリケーションのパフォーマンスへの影響を確認する上で役立ちます。これがないと、チューニングは「ノブをランダムに回している」だけになります。
注意:
Oracle の VM に関しては、以下にも情報があります。
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html