アプリケーション性能モニタリングソリューションJENNIFERの主要な機能であるスタックトレースレコーダー（スタックトレースのサンプリングを利用した性能分析）を利用し、性能改善作業を行ったJENNIFER開発担当者の経験談です。
全体に影響を及ぼすチューニングで満足のゆく性能改善を目指す開発者にとって若干でも参考になれば幸いです。

概要

スタックトレースのトレース機能を利用して性能分析を行うスタックトレースレコーダー(Stacktrace Recorder) で求められることは、性能改善作業のときに参考になる情報を提供することです。
性能改善はトラブルシューティングとアプローチが異なります。トラブルシューティングの場合、トラブルが発生して原因が明確になったとき、その原因を除去するか対策を取れば完了です。
一方、性能改善は原因が明確ではない場合は仮説を立てて、再現テストを実施し、トラブルが再現するまで、仮説を変えて再現テストを繰り返すことで原因を特定します。性能改善は問題が発生しているのではなく、要求事項が発生した場合に、それを解決するプロセスです。

例えば、次のような要求事項が性能改善を行う理由です。

• 性能に目標値が求められる場合　例）1秒以内にリクエストを処理する。
• 処理時間が遅くなったので確認する場合　例）応答時間が遅くなった気がする。
• システムの修正、利用するプログラム(ライブラリ)のバージョンが変更された場合　例）エージェントのインストール又はアップグレードしたら遅くなった。

このような理由で性能改善を行うプロセスは次の通りです。

要求又は検知 → 再現環境の構築と再現テスト → 測定 → 改善 → 検証のための測定(目標値の達成まで繰り返す)

性能改善のプロセス

要求又は検知

ある日、開発担当者のAさんは次のような性能改善の依頼を受けました。
「JENNIFER V4バージョンからV5へアップグレードしたが、応答時間が遅くなりCPU使用率も0.5 ~ 1%多くなっているように見えるので確認してほしい!!!」

再現環境の構築と再現テスト

先ず、改善作業を行うために、要求事項が正しいのか、どのような特徴があるのかを確認する必要があります。
確認作業のためには要求事項に近いテスト環境の構築とプログラムの再現テストを行います。そして、プログラムの再現テストのときに無駄な試行錯誤をしないためには、アプリケーションの構成を把握する必要があります。これは重要な作業です。正確に把握できれば再現し易いですが、十分に把握できていないケースが多くあります。
再現環境の構築とプログラムの再現テストの準備が終わると、エージェントをインストールして、全般的な状態のデータを収集します。

測定

複数のオプションを変更したことで、応答時間が速くなって、CPU使用量も減少したことが確認できます。

オプションの変更だけで全ての改善ができれば良いですが、もう少しチューニングを行います。

関連するメトリクスを幾つか追加すると、データ上では応答時間に顕著な差を確認できます。もう少し改善できる余地がありそうです。

改善

ユーザを満足させるために、プログラムの性能改善をするには幾つかの方法があります。
アルゴリズムの最適化、コードの最適化、ハードウェアのアップグレード、並列処理、キャッシング、メモリ管理、プロファイリングでボトルネックを探すなど多くの方法があります。

今までは、プロファイリングで改善のポイントを探す方法がベストでした。
しかし、この方法では値の差が顕著に現れる場合は良いですが、その差が少ない場合は期待する程のメリットが無い場合もあります。また、スレッドダンプで探す方法もありますが、正確ではありません。
以前はシェルまたはその他CLIツールで時間を決めて記録した後、エクセルを使い一つずつ手作業で分析するのが一般的な方法でしたが、今ではスタックトレースレコーダーでできます。 スタックトレースレコーダーでプロセスCPU使用率が高い時点で収集されたスタックを分析してチューニングポイントを探します。その時点のスタックで、共通で多く呼ばれているメソッドの性能を改善することが目標です。

次の手順で分析を進めていきます。

• ①スタックトレースの収集
• ②フレームスコープチャート分析
• ③メソッドテーブル及びフレームチャート分析
• ④コードの修正

スタックトレースの収集

改善ポイントを探すために、自動スタックトレース機能を設定して、スタックを収集し、スタックトレースレコーダーを利用して内容を分析します。

フレームスコープチャート分析

自動スタックトレース設定をして、時間が経過すると、スタックトレースデータが収集されます。
CPU使用率の改善のため、プロセスCPU使用率を選択して、フレームスコープチャートで収集されたスタックトレースを分析する時間帯を選択します。

メソッドテーブル及びフレームチャートでメソッド分析

コードの修正

疑わしい部分のコードを修正してオプションを追加するなどの改善作業を行います。

検証のための測定(目標：CPU使用率を平均1%改善)

改善作業後に、再度収集されたスタックの内容が次の画面になります。

最初にスタックトレースレコーダー画面だけを見ると、改善が確認できません。しかし、収集されたスタックの内容が異なっていることだけは確認できます。
ところが、詳細にデータを見ると多くの性能改善があったことを確認できます。スタックトレースレコーダーで改善された内容を確認することは簡単ではありませんが、JENNIFERの性能ブラウザで改善の前後を比較できます。

テスト結果で性能の差が確認できましたか?
今回、実行したテストではSQLの実行が多いですが、応答時間は約50倍、CPU使用率は6倍程度に性能が改善されたことを確認できます。

スタックトレースレコーダーの搭載以前にはこのような性能改善、つまり部分的ではなく全体的な性能改善が必要な場合は、周期的なスレッドスタックの収集がベストでした。多くのツールがありますが、操作が簡単ではなく、過去のデータを保持できません。エクセル又はメモ帳を使って手作業で一つずつ比較する必要がありますが、このような作業ができる人も限られます。
JENNIFERのスタックトレースレコーダー機能のリリース以降では、開発側だけでなく運用側からも内容の確認を依頼することができるようになり、何より経験が浅いメンバーでも性能改善作業を行うことができることで、性能改善の難易度を下げたことが最も大きな成果であると考えています。