単体性能の検証で問題がなくても、複数のトランザクション処理でスループットが悪いなどの問題が潜んでいることもある。これは、DBサーバ接続時などの排他処理に要因があると考えられる。多重性能の検証では、このような単体の検証では見つからない個所に性能劣化の要因がないかを確認する。
多重性能の検証も、処理時間に関する性能要件とメモリに関する性能要件の両面から検証する。まず、処理時間に関する検証について説明しよう。処理時間に関する性能要件には、TPS(Transaction Per Second:1秒当たりのトランザクション処理件数を指す単位)およびレスポンス時間があり、多重性能の場合も順を追って検証していく。性能要件の検証順序、検証する内容、性能要件を満たしていない場合に考えられる要因を次の表にまとめる。
検証順序 | 性能要件 | 検証する内容 | 考えられる主な要因 |
---|---|---|---|
1 | TPS | Webサーバのアクセスログを参照して、複数のトランザクションを同時実行しても問題がないかどうかを検証する | ログなどのリソースの排他や、DBアクセスの排他によって、同じリソースを扱うスレッドが競合する |
2 | レスポンス時間 | 負荷ツールを使用して、ネットワーク部分でのデータのやり取りを検証する | データの転送回数が多過ぎる |
また、性能要件の個所を図で示す(図中の項番は表の「検証順序」と対応している)。
多重性能の場合も1項目ずつ性能を検証していき、性能要件に問題がないかを検証する。では、それぞれの要因の対処方法を説明する。
次に、メモリに関する性能要件を処理時間とは別に検証する。多重性能でのメモリに関する検証では、Full GCの発生頻度が想定範囲内であるかどうかを確認する。Java VMのGCログを参照して、問題がある場合は、Javaヒープサイズを見直そう。
多重性能の検証で目標とする性能を満たしていれば、性能要件の検証は完了だ。
ここまで紹介したように、設計段階でWebシステムの性能目標を設定し、プロトタイプで今回説明した単体性能や多重性能を検証することで、早期に性能確認や必要なハードウェアの見直しができるようになるだろう。
企業向け情報を集約した「ITmedia エンタープライズ」も併せてチェック
Copyright © ITmedia, Inc. All Rights Reserved.