本番稼働中のWebシステムの性能を計測する「Web性能管理ソフト」への関心が高まっている。製品を提供するベンダーからは，「年間で約40％ずつ売り上げが伸びている」（ベンダーの担当者）といった声も聞く。
Web性能管理ソフトとは，クライアントがWebサーバーにHTTP（Hyper Text Transfer Protocol）リクエストを送信してから，レスポンスを受信するまでの時間（＝レスポンス時間）を定期的または常時，測定するツールである（図1）。レスポンス時間は本番環境の状況次第で変化するため，カットオーバー後も継続的に計測することが，運用担当者にとっても開発担当者にとっても不可欠になってきた。
 |
| 図1●Web性能管理ソフトの機能と必要な理由 Web性能管理ソフトとは，本番環境下でリクエストを送信してからレスポンスを受信するまでの時間（＝レスポンス時間）を測定する機能を持ったツールである。本番環境にはアクセス増など変動する要素があるので，定期的または常時，監視する必要がある [画像のクリックで拡大表示] |
例えば運用担当者にとっては，「サーバー機の死活監視だけでは気付かなかったサービスの停止や性能劣化を把握しなければならない」（ディーシーカード デジタル事業推進部 インターネット推進グループ 部長代理 小林良彦氏）という現実がある。一方の開発担当者にとっても，既存システムを拡張するときに，「性能をデグレード（低下）させないための目標値を把握する」（大手製造業A社の開発担当者）ために，カットオーバー後のレスポンス時間を計測することが極めて重要になってきている。
［知る］人手では測れない内訳を計測製品タイプは4種類
| 表1●主要なWeb性能管理ソフト [画像のクリックで拡大表示] |
 |
もちろん，レスポンス時間はストップウォッチ片手に人間が測定しても構わない。しかしWeb性能管理ソフトを利用すれば，人手では測れない詳細な情報を正確に計測・分析できる。これが，Web性能管理ソフトを利用する最大のメリットだ。
典型的なのは，レスポンス時間の内訳を記録し，表示できること。ほとんどの製品が，こうした機能を備える（表1）。内訳の詳細こそ製品ごとに異なるが，図2で示すような時間を計測できる。
 |
| 図2●Web性能管理ソフトが計測できるレスポンス時間の内訳 取得できる情報は製品によって異なるが，多くの製品はTCP/IPの仕組みを応用し，レスポンス時間の内訳を掘り下げて記録できる。平常時のデータと性能問題発生時のデータを比較すれば，原因個所がネットワークかサーバー（アプリケーション）かを一次切り分けできる [画像のクリックで拡大表示] |
計測したレスポンス時間の内訳を見ると，レスポンス低下時にボトルネック個所を大まかに絞り込める（一次切り分けが可能になる）。例えば平常時に比べて「名前解決時間」や「TCPコネクション確立時間」がかかっていたとすると，トラブルの原因はネットワーク周りにある可能性が高い。「サーバー処理時間」に遅延が見られるときは，Webサーバーやアプリケーションのボトルネックが疑われる。実際，製品ベンダーによれば，「性能上のトラブルが起きてから，問題を切り分ける目的で製品を導入するケースが少なくない」（ベンダーの担当者）という。
実クライアントと仮想クライアント
Web性能管理ソフトは，レスポンス時間の測定方法と実装形態の違いで，4種類に大別できる（図3）。
 |
| 図3●Web性能管理ソフトの製品タイプ 実際のクライアントのリクエストに対するレスポンス時間を常時記録するタイプと，仮想的なクライアントが定期的に疑似リクエストを発行してレスポンス時間を測定するタイプに大別できる。それぞれの実装形態にも2タイプあるので，合計4種類となる [画像のクリックで拡大表示] |
測定方法は2タイプある。一つは，Webシステムの実際の利用者が使うクライアントからのレスポンス時間を常時記録するタイプ（ここでは「実クライアント型」と呼ぶ）である。もう一つは，測定者が任意の場所に設置した計測用クライアントが「疑似リクエスト」を出し，そのレスポンス時間を定期的に測定するタイプ（同「仮想クライアント型」）である。
一つ目の実クライアント型は，利用者が現実に体感している性能の「生データ」を取得できることが強みだ。二つ目の仮想クライアント型は，生データの取得はできないものの，作成したシナリオ（操作パターン）に基づき，特定のURLのレスポンス時間や複数のページを遷移させたときのトータル時間を定点観測できるメリットがある。
実装形態はそれぞれ2タイプ
実クライアント型の実装形態には，実クライアント上に「エージェント」と呼ぶレスポンス時間の計測ソフトを必要とするタイプ（ここでは「エージェントあり型」と呼ぶ）と，不要なタイプ（同「エージェントなし型」）がある。
実クライアント型のエージェントはActiveXやJavaScriptで実装されているので，あらかじめクライアントに配布しておく必要はないが，エージェントをクライアントがダウンロードできるようにサーバー側のアプリケーションを書き換える手間がかかる。また，Webブラウザの設定やアプリケーションの作り方によっては，エージェントが期待通り動かないこともある。その半面，エージェントできめ細かな情報を取得できる。一方のエージェントなし型は，LANスイッチのミラー・ポートを使って実クライアントとWebサーバーの間で交わされるパケットを管理サーバーに転送し，分析する。既存システムの変更なしで導入できる手軽さがメリットだ。
仮想クライアント型では，エージェントは必須となるが，エージェントの実装形態で二つのタイプに分かれる。仮想クライアントからWebサーバーに送信するデータを再現するタイプ（ここでは「通信再現型」と呼ぶ）と，仮想クライアントに対するユーザーのキーボードやマウスの操作を再現するタイプ（同「イベント再現型」）である。
通信再現型は，リクエスト送信にWebブラウザを使用しないので仮想クライアントのリソース（CPU/メモリーなど）の使用量が少なくて済む。その分，同時に多くの疑似リクエストを送信できる。イベント再現型はリソース使用量は多くなりがちだが，実際の利用者と同様にWebブラウザを使ってアクセスするので，利用者の体感レスポンス時間に近い測定結果を得られる。
＞＞後編
