Webシステムの性能要件を検証する「手順と実践」：Java Review（1/2 ページ）

Webシステムの性能設計後には、性能要件をあらかじめ実機マシンで検証しておくとよい。検証の目的は、マシンサイジング時に設定した内容や機器構成が、性能要件を満たしているかどうかを確認するためである。今回はWebシステムの性能要件の検証手順や考え方について紹介する。

[友成文隆（日立製作所），ITmedia]

Webシステムの性能要件の検証手順

　まずは、性能検証の流れを押さえておこう。検証は次の流れで実施する。

1、単体性能の検証　単体性能の検証では、1トランザクションの処理性能を検証する。

2、多重性能の検証　単体性能の検証で問題ない場合は、多重性能の検証を実施する。多重性能の検証では、複数トランザクションの処理性能を検証する。

　本稿では、Webシステムの性能検証のうち、単体性能および多重性能の検証を中心に説明する。どちらの場合も性能を検証するには、処理時間に関する性能要件とメモリに関する性能要件を確認する必要がある。性能要件に問題がある場合は、要因を切り分けて対処する。

　以降で、単体性能の検証、多重性能の検証について説明する。

単体性能の検証

　単体性能を検証する場合、1トランザクション当たりの処理性能を、処理時間に関する性能要件とメモリに関する性能要件の両面から検証する。

　まず、処理時間に関する検証について説明しよう。処理時間に関する性能要件には、実行CPU時間、アプリケーションサーバ内部の保留時間、およびレスポンス時間があり、各性能要件を、順を追って検証していく。性能要件の検証順序、検証する内容、性能要件を満たしていない場合に考えられる要因を次の表にまとめる。

検証順序	性能要件	検証する内容	考えられる主な要因
1	実行CPU時間	OSの稼働統計を参照して、CPU処理時間が長過ぎないかを検証する	処理ロジックが冗長である
2	アプリケーションサーバ内部の保留時間	Webサーバのアクセスログを参照して、アプリケーションサーバ内、およびDBなどのバックエンド処理部分の処理を検証する	ディスクI/Oの回数が多過ぎる、またはSQL文の発行回数が多過ぎる（DBサーバと接続している場合）
3	レスポンス時間	負荷ツールを使用して、ネットワーク部分でのデータのやりとりを検証する	データの転送量が多い

　また、性能要件の個所を、以下の図で示す（図中の項番は表の「検証順序」と対応している）。

　図中のグレーの矢印はリクエストおよびレスポンスの流れを示す。性能検証は、図中の項番の順で1項目ずつ実施する。性能要件が満たされていない場合は、要件が満たされるまで要因の見極めと対処を繰り返す。要件を満たしたら、次の性能要件を検証する。

---

　では、マシンサイジングによって必要なリソースが確保されている場合に、性能要件を満たしていないときの対処方法について説明しよう。

　実行CPU時間を満たさない場合、次の対処を実施する。

1. 業務アプリケーションの処理ロジックが冗長でないかを見直す
2. 上記で解決しない時には、CPUのサイジングを再検討し、マシン台数の増設を検討する

　アプリケーションサーバ内部の保留時間を満たさない場合、次の対処を実施する。

1. 業務アプリケーションのI/O処理やSQL文の発行に関する処理を見直す
2. 上記で解決しないときには高性能なディスクに切り替えて、ディスクI/Oを強化したり、DBサーバの負荷を減らすためDBサーバを増強したりすることを検討する

　レスポンス時間を満たさない場合、次の対処を実施する。

1. 業務アプリケーションのデータ転送に関する処理を見直す
2. 上記で解決しない時にはネットワーク機器を増強するなどの物理的な対策を検討する

　ここで、それぞれの対処方法の「1」に該当する業務アプリケーションの見直しについて簡単に説明しておこう。まず、それぞれ問題となる処理のロジックを見直す。ただし、やみくもにロジックを見直すのでは、見直し範囲が広くなり、効率も良くない。そこでロジックを見直す際には、併せてアプリケーションサーバのログやトレース情報も参照するとよい。

　場合によっては、アプリケーションサーバのログとDBサーバのログといったように複数のログの突き合わせもしてみる。これらの情報を使用すれば、見直し対象となる処理の中で実行時間の長い個所を調査できるため、問題となるロジックを絞り込めるはずだ。

　なお、日立のCosminexusを使用している場合は、「性能解析トレース機能」を使用するとよい。この機能は、リクエストごとに一意のIDを割り振り、アプリケーションサーバ内での処理ポイントでトレース情報を出力するので、利用者は問題があるリクエストと処理を調査しやすくなる。特にデータベースとして、Oracleや日立のHiRDBを利用している場合、性能解析トレース機能ではコネクションIDも労として出力する。

　これらによって、WebサーバからDBサーバまでの処理シーケンスを容易に把握できる。問題が見つかったら、コーディングを修正しよう。

　以上が、単体性能の検証の流れだ。なお、単体性能を大まかに検証したいなら、最初にレスポンス時間を検証する方法もある。レスポンス時間に問題があると思われる場合は、問題の個所を絞り込むため、実行CPU時間などの細かい単位で問題がないかをみていこう。

　問題点をすべて解決できたら、処理時間に関する検証は完了だ。

　次に、メモリに関する性能要件を、処理時間とは別に検証する。単体性能でのメモリに関する検証では、Java VMのGCログから1トランザクション当たりで消費するJavaヒープ量を確認する。確認の結果、要件を満たさない場合は、インスタンスの情報が多過ぎることなどが考えられる。

　対処方法はまず、処理時間の場合と同様に、業務アプリケーションを見直すことだ。なお、日立のCosminexusを使用している場合、メモリ使用量の確認には「クラス別統計機能」を使用するとよい。この機能では、クラスのインスタンスのメモリ使用量を、クラスの参照関係とあわせて出力できるため、メモリ不足の原因となるクラスを絞り込める。業務アプリケーションの見直しで問題を解決できない場合は、メモリのサイズを再検討しよう。

　処理時間およびメモリに関する性能要件をすべて満たしたら、単体性能の検証は完了だ。多重性能の検証に移ろう。