1.応答時間分布グラフ

応答時間分布グラフは、Y軸が応答時間、X軸がトランザクションの終了時間を表す点グラフです。各点（ドット）は一つのトランザクションを意味します。
これにより詳細な追跡をすることができます。

応答時間分布グラフは、一般的な他の方法＊に比べ、トランザクションが実行される過程で存在するボトルネックをより効果的に検知することができます。

＊他の方法とは、各種キューモニタリング、JNDIモニタリング、メソッド追跡など、統計的な方法を利用した分析方法のことです。

事例1:初期化過程で発生するボトルネック現象

下記のグラフは、自然な現象であり、特に問題は見られません。
イベントを開催するサイトや、申し込み受付等のサイトでよく見られる応答時間分布パターンです。その他にも、年末年始のチケット販売、特別バーゲンセールサイト等でも同じような現象が起こる可能性があります。

このような現象が発生した場合に注意すべきことは、瞬間的なシステムへの多重アクセスとアプリケーションの初期化が重なることで、システムがダウンする可能性があるということです。
本事例はボトルネック発生後、5分で正常化されましたが他のボトルネックの要素がシステムに相互作用した場合、次のようなグラフ事例（事例２）になる可能性があります。

事例2:多重アクセス後、障害状況

本事例は、事例1)と似た条件下にありましたが、障害状況が解決できず長時間継続する現象です。
11時にイベントがあり、この約10分前からトランザクションが増加して、11時にはシステムがかなり遅い状況になっています。そして1時間経過後も解決できていない状況であることが読み取れます。
この場合は(砂嵐現象)、システムのチューニングが必要になります。

この現象に対する有効なチューニング方法は、JENNIFERのPLC（Peak Load Control）機能を適用することです。
遅いプログラムを選別してチューニングすることは勿論ですが、PLCはシステムの多重アクセス時、システムが耐えられる程度のトランザクションのみを受け入れるようにするため、より安定した運用が可能になります。
また、本グラフの特集状況より、横ラインの有無(横ライン現象)を確認することが可能になります。珍しいケースではありますが、この現象が発生した場合、何かしらの分析が必要になります。

事例3:ボトルネック現象

本グラフはボトルネックが発生した状況です。
応答時間分布グラフの特徴上、トランザクションが終了して、画面に点を出力するため、ハング状態ではありませんが、瞬間的に固まる現象が発生した場合、次のように縦に列が作られます。

本グラフを分析する時には、柱を含むトランザクションのみを分析する必要があります。
画面上には同じトランザクションが幾つか存在することがあり、柱に含まれたトランザクションより応答時間が遅いトランザクションが存在する場合もあります。
このような場合、他の統計的方法によるプロファイリング又はサンプリング方法では、正確に把握することができません。

事例4:深刻なボトルネックの発生

事例3)の状況が深刻になった場合、以下のようなグラフになる可能性があります。

水柱が深刻な状況となった場合を滝現象といいます。
この場合は通常リアルタイムプロファイリング、サンプリングまたは、良く適用された応用プログラムログだけを検出することも可能です。バッファーのプールまたは深刻なsync、データベースロックなどが存在する場合に現れるグラフです。

事例5:照会件数による応答時間偏差

応用プログラムの応答時間が遅くなる原因にはいろいろな要素があります。ネットワークが遅い、またはDBロックでのシステムリソース不足など、理由も現象も様々です。
多数のAPMソリューションでは、EJB、Servlet、JNDI、JDBC、NETなどをモニタリングして問題を解決する方法をとっています。
しかし、このような方法には盲点があります。

ここで紹介する例は、A classとB classの二つのモジュールがあるとします。Aは1,000rowsを照会するのに対し、応答時間が10秒です。Bは400rowsを照会するのに8秒、100rowsを照会するのに1秒かかります。
では、AとBをどうやってチューニングするべきでしょうか？
Aに関してはSQLチューニングまたはCache、プログラム分割などの観点からのアプローチが効率的であると考えられます。また、Bはfetch件数を減らす方法を検討することが最適であると考えられます。

事例6：ユーザ増加による応答時間の遅延

本事例はユーザの増加に反応して、応答時間が急激に遅くなる状況のグラフです。
応答時間分布グラフをモニタリングすると、リクエスト数によって応答時間が急激に反応する場合があります。一定の数を超えた時だけキューイングが発生するシステムと連携する場合、発生する可能性が高いです。

ここで紹介する例は、検索システムとの連携が原因となっている場合の問題です。
大容量のファイルログ（file log）なども同じようなグラフになる場合があります。テストシステムでは問題を確認することは困難ですが、運用システムでは発生する可能性があります。該当プログラムに対する実使用量の分布であるため、発生する可能性があります。また、システムの特定のボトルネックが特定プログラムだけに影響を与える場合にも発生する可能性があります。

事例7：小さく頻繁なボトルネック発生(マトリックス現象)

非定期、不特定トランザクション間にロックが頻繁に発生する場合に見られるグラフです。
データベースでShared Lockが頻繁に発生する場合が代表的です。

理論的にランダムsyncが不特定トランザクションに影響を与える場合のみ、このグラフが発生します。この場合は、システムに対するアーキテクチャーまたはビジネスについて検討する必要があります。

事例8：応答時間の統計的遅延

平均応答時間が負荷の有無に関わらず遅延する場合です。
マトリックスのように急激ではありませんが、応答時間の散発的遅延現象は主にバッファー不足で発生する可能性が高いです。全体トランザクションに影響を及ぼすため、DB、システム、ネットの全体プログラムに関連する問題となります。該当グラフはDBのbuffer cache latchによって発生したものです。

2.結論

従来のモニタリング方法は、メソッドの応答時間をログに記録し、それを統計的分析によって遅延要素を判断する方法がほとんどでした。
しかし、通常応用プログラムのログを記録する方法はトランザクションの概念が薄く、またリソース中心のモニタリングツールを使って、具体的に分析するアプローチ方法については、分析の対象を誤る可能性がありました。従って、システムにおいて問題の可能性があるトランザクションを中心に、具体的にかつ詳細な分析を行う方法こそが、素早く、有効な分析を可能にする方法であると考えられます。
JENNIFERの応答時間分布グラフは、ボトルネックを検出して、チューニングを行うことにより、問題分析の手助けをします。