Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。
あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。
今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。
性能を見積もるメリットは二つ
設計段階では動作するプログラムが存在しないので、性能評価においては、机上で試算する方法が一般的だと思います。設計段階から机上試算で性能評価を行う目的は大きく二つあります。
（a）設計した機能のレスポンス時間について一定の目安を得る
一つ目の目的は、性能を作り込むべき機能を明らかにすることです。
机上試算での性能評価は精度が粗いものの、明らかに性能トラブルにつながる機能を抽出することが可能です。この段階で抽出された機能は「設計の見直しを検討する」「機能の簡略化を検討する」「目標レスポンス時間の伸長を検討する」といった対策を取ることになります。実装が始まったあとはいずれも困難な対策ですが、設計段階なら可能です。
（b）開発担当者に性能対策を意識させる
設計段階から机上試算を実施した結果は、設計担当者にドキュメントとしてまとめてもらいます。これによって設計担当者は、機能面と同時に性能面をも意識せざるを得なくなり、性能的に実現不可能な機能仕様を防止することにつながります。これが二つ目の目的です。
設計担当者はこれまで、機能面の設計品質を確認するために画面設計書などの設計書は作成しますが、性能品質を確認する設計書は作成しないことが多かったと思います。「性能品質を確認せよ」といっても、設計書のような何かしらのアウトプットを義務付けないと、設計担当者の意識は「機能品質＞性能品質」となるのは仕方のないことでしょう。
具体的な性能見積もり例
以降、Webシステムのオンラインアプリケーションにおける性能見積もりの方法について説明します。
まず処理時間を見積もる範囲は、この連載の第2回でも説明したWebサーバー内処理時間とし、利用環境による変動が大きいWebブラウザー、ネットワーク部分の処理時間を除きます。処理時間は［1］静的コンテンツ処理時間、［2］APサーバープロセス処理時間、[3]業務ロジック処理時間、［4］SQL解析時間、［5］ディスクI/O時間の五つに分解し、これに［6］余裕率を掛けて、見積もり時間とします（図1）。それぞれの算出方法を示しましょう。
［1］静的コンテンツの処理時間
Webサーバー上で実行される静的コンテンツの処理時間は、以下のように計算します。
処理時間 ＝ (1画面のコンテンツ数) ÷ (ブラウザーの同時接続数) × (1ファイル当たりアクセス時間)
1ファイル当たりアクセス時間は、想定するハードウエアで実測する場合と、構成が似た過去のシステムでの計測結果を利用する場合があります（［2］～［6］についても同様です）。実測する場合は、ブラウザーからサーバー上の静的コンテンツにアクセスしたときにおける、HTTPサーバープロセス（Apache、IISなど）の滞留時間（リクエストを扱うのにかかった時間）の平均値を使用すればよいでしょう（図2）。
なおこの処理は通常、処理全体に占める割合がかなり小さいため、余裕率に吸収してもかまいません。
［2］APサーバープロセスの処理時間
APサーバープロセス自体の処理時間は、APサーバープロセス（TomcatやWebLogic Serverなど）のアクセスログに滞留時間を出力させて計測します。実測する場合は、ほとんど業務処理のないロジックを実行したときの滞留時間の平均値を利用すればよいでしょう（図3）。
［3］業務ロジックの処理時間
APサーバー上で動く業務ロジックの処理時間は、画面に出力する項目数をベースに以下の式で見積もります。
業務ロジック処理時間 ＝（画面項目数）×（1項目当たりアクセス時間)
1項目当りのアクセス時間は、業務ロジック実行時のAPサーバー滞留時間から「[2]APサーバープロセス処理時間」を引いた値を求め、それを（画面項目数）で割った値を利用します。実測する場合は、プロトタイプを開発します。
業務ロジックの処理時間は本来、業務ロジックごとに異なりますが、DBサーバーの処理時間に比べて影響は小さいので、平均的な業務ロジックのみを定義し、そのほかは「処理の重さ」を考慮して補正する形でかまいません。
［4］SQL文解析処理時間
SQL解析処理時間は、DBサーバーがSQL文を解析する時間のことです。厳密には実行するSQL文によって変わりますが、見積もり段階では一律で算出してかまいません。
［5］ディスクI/Oの処理時間
ディスクI/Oの処理時間は、SQL文の実行時に発生するディスクI/Oの所要時間のことです。ディスクI/Oは、コンピュータで最も遅い処理の一つなので、レスポンス時間の見積もりには最も重要です。1回のディスクI/O時間は、ディスク構成が近い環境での実測値を使用するのがよいでしょう。
ディスクI/Oは、DBサーバー内のキャッシュがヒットすれば発生しません。SQL文ごとにキャッシュヒットが期待できるものとできないものを区別して、キャッシュヒットが期待されないものに対して処理時間を見積もります。
［6］余裕率
安全をみて、余裕率は1.5～2倍程度にしておきます。
最後に［1］～［6］で算出した性能基礎データを使って、機能単位でレスポンス時間を見積もります。図4のような性能見積もり用の定形シートを作成しておくと作業を進めやすくなるでしょう。なお［1］～［6］をすべて勘案してサーバー処理時間を算出するのが理想ですが、工数がかけられない場合は、レスポンス時間への影響が大きいDBサーバー処理時間（［4］＋［5］×［6］）に限定してもかまいません。
TIS 技術本部 先端技術センター 主査
