第5回　性能テストでは選択と集中を心がけよう

　性能テストは開発したシステムの性能要件が確保されていることを確かめる重要な工程です。しかし、リリースの直前に実施されることが多いため、問題が判明してもチューニングを行う時間が取れない状況に陥ることもあります。

　そこで筆者は、性能テストを計画的に実施するため、機能ごとにメリハリを付けるようにしています。問題が判明してから、対策（チューニング）して確認するサイクルを回せる時間を確保するためです。

　性能テストでメリハリを付けた例を図1に示しました。図1では「重点機能」と「それ以外の機能」の2種類に分けて、性能テストの内容を変えています。重点機能に対しては、稼働時と同等の負荷をシステムにかけてテストする「負荷テスト」を追加で実施します。

図1●性能テストの計画例

[画像のクリックで拡大表示]

　負荷テストの対象になる重点機能として、まず候補になるのが「よく使われる機能」です。負荷テストでは、よく使われる機能を実行して、本番運用時を想定した負荷をシステムに与え、性能要件を満足するかをチェックします。

　重点機能のもう一つの候補が、性能要件を具体化した連載第2回で示した「性能重視の機能」です。性能重視の機能は、性能要件を守れなければ、ビジネス機会の損失につながるような機能のこと。負荷をかけた状態でもレスポンス時間を実現できるかをチェックする必要があります。

　図1のそれぞれの工程について解説していきましょう。重点機能もそれ以外の機能も、［1］単体性能テスト、［2］チューニング、［3］確認をまず実施します。

［1］単体性能テスト
　各機能の単体性能として、ほかの機能が稼働しない状態で性能を測定し、レスポンス時間、使用リソース（CPU、メモリー）を評価します。

［2］チューニング
　［1］で目標を超過した機能に対して、対策を検討し、プログラム修正などのチューニングを実施します。

［3］確認
　［2］でチューニングをした機能に対して、［1］と同一条件でテストします。その結果、期待したチューニング効果があり、性能問題が解消したことを確認します。解消しなければ［2］でチューニングに戻ります。

　重点機能については、さらに［4］負荷テストと［5］チューニングを実施します。この工程に進むのは、［1］～［3］で単体性能に問題がないと確認できたことが前提になります。

［4］負荷テスト
　ピーク時における機能の件数比から、本番運用時を再現する負荷テストのシナリオを作成し、負荷ツールなどを用いてテストを行います。

［5］ チューニング
　［4］で問題となった機能に対して、プログラム修正などのチューニングを実施します。単体性能は確認済みなので、データベースロックなど複数機能のI/O競合というようなことが主要因となるでしょう。

　最後に［6］最終テストを実施します。単体の各機能に対して、性能チューニングをすべて行った状態で、システムの性能要件を確認するテストのことです。ここでシステムリリースに問題のない性能かどうかを最終評価し、これ以降のプログラム修正を凍結します。万一、残った問題は機能品質の低下を防止するために、原則プログラム修正以外の対策を検討します。

　今回の連載では「いかに性能品質を作りこんでいくか」をテーマとして、性能をマネジメントするための考え方やノウハウを紹介してきました。現場の皆さんの手助けになれば幸いです。