Webシステムの性能要件を検証する「手順と実践」:Java Review(2/2 ページ)
Webシステムの性能設計後には、性能要件をあらかじめ実機マシンで検証しておくとよい。検証の目的は、マシンサイジング時に設定した内容や機器構成が、性能要件を満たしているかどうかを確認するためである。今回はWebシステムの性能要件の検証手順や考え方について紹介する。
多重性能の検証
単体性能の検証で問題がなくても、複数のトランザクション処理でスループットが悪いなどの問題が潜んでいることもある。これは、DBサーバ接続時などの排他処理に要因があると考えられる。多重性能の検証では、このような単体の検証では見つからない個所に性能劣化の要因がないかを確認する。
多重性能の検証も、処理時間に関する性能要件とメモリに関する性能要件の両面から検証する。まず、処理時間に関する検証について説明しよう。処理時間に関する性能要件には、TPS(Transaction Per Second:1秒当たりのトランザクション処理件数を指す単位)およびレスポンス時間があり、多重性能の場合も順を追って検証していく。性能要件の検証順序、検証する内容、性能要件を満たしていない場合に考えられる要因を次の表にまとめる。
検証順序 | 性能要件 | 検証する内容 | 考えられる主な要因 |
---|---|---|---|
1 | TPS | Webサーバのアクセスログを参照して、複数のトランザクションを同時実行しても問題がないかどうかを検証する | ログなどのリソースの排他や、DBアクセスの排他によって、同じリソースを扱うスレッドが競合する |
2 | レスポンス時間 | 負荷ツールを使用して、ネットワーク部分でのデータのやり取りを検証する | データの転送回数が多過ぎる |
また、性能要件の個所を図で示す(図中の項番は表の「検証順序」と対応している)。
多重性能の場合も1項目ずつ性能を検証していき、性能要件に問題がないかを検証する。では、それぞれの要因の対処方法を説明する。
- TPSを満たさない場合、ログなどのリソース排他でもDBアクセスの排他でも、アプリケーションサーバのログやトレース情報から、業務アプリケーション内で性能劣化の要因となる処理を特定する。なお、性能解析トレース機能を使用すると、処理の特定がしやすくなる。処理が特定できたら、コーディングを見直す
- レスポンス時間を満たさない場合、転送遅延が発生していないかなどをアプリケーションサーバのログやトレース情報を基に調査する。問題がある場合はネットワーク機器の強化を検討する。ネットワーク機器を強化しても問題が解決しないときには、データ転送処理に関するコーディングを見直す
次に、メモリに関する性能要件を処理時間とは別に検証する。多重性能でのメモリに関する検証では、Full GCの発生頻度が想定範囲内であるかどうかを確認する。Java VMのGCログを参照して、問題がある場合は、Javaヒープサイズを見直そう。
多重性能の検証で目標とする性能を満たしていれば、性能要件の検証は完了だ。
ここまで紹介したように、設計段階でWebシステムの性能目標を設定し、プロトタイプで今回説明した単体性能や多重性能を検証することで、早期に性能確認や必要なハードウェアの見直しができるようになるだろう。
企業向け情報を集約した「ITmedia エンタープライズ」も併せてチェック
関連記事
- Webアプリの性能やメモリ関連の問題を、コーディング時に回避
- Webシステムにおける「文字コード変換の落とし穴」
- Java VMのメモリ不足――原因切り分けから解決まで
- “Don’t”Stop the World――Full GCへの対策
- JavaVMのメモリ管理をマスターする
- ITアーキテクトに求められる「Javaの互換性やサポート」という視点
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.