Webサイトのパフォーマンス問題を明確にするマーキュリーの「Topaz」技術（3）
| 【国内記事】 | 2002.4.04 |
問題点を掘り下げて解決策を導き出す
それでは，ZDNetおよびSBPのサイトのレスポンスを悪化させる原因は，どこにあるのだろうか。そこで12時〜13時の「トランザクションのブレークダウン」を分析してみることにする。
 |
| 12時〜13時の「トランザクションのブレークダウン」のグラフ |
ZDNetトップページ，Enterpriseチャンネル，e-ビジネスチャンネルについては，接続時間（オレンジ色）が非常に長くなっている。これにより問題点は，Webサーバの接続要求処理能力にあることが分かる。それに対し検索ページでは，サーバ時間（緑色）が非常に長く（約5秒）なっており，サーバの処理能力に問題があるという。
「一般的に検索処理はサーバ処理時間が長くなる傾向にあるが，平均5秒という結果はかなり重い」と福田氏。
いやはや面目ないかぎり……。
「一方，SBPは，データサイズが大きいため，ネットワーク時間（ダウンロード時間：黄色）が長くなっている。ただし，接続時間（オレンジ色）が非常に短いことから，Webサーバの接続要求に対する応答状態はZDNetに比べてかなり良好と言える」（福田氏）
このような問題を解決するためにActiveWatchでは，Webサイトで利用されているコンポーネントの状況をブレークダウンすることもできる。これにより，どのコンポーネントが重いのかを明確にすることが可能だ。
 |
| ページコンポーネントブレークダウンのグラフ |
表示されている結果は，SBPではなくZDNetトップページの各コンポーネントのダウンロードにかかった時間を表している。これらのグラフからは「どのコンポーネントのダウンロードに時間がかかっているのか」「各コンポーネントがどういった順序でダウンロードされているか」「アプリケーションの実行に時間がかかっていないか」などの状況を明確にすることができる。
そのほかActiveWatchでは，Webトレースの計測結果を分析することも可能だ。例えば，TopazエージェントとSBP間，TopazエージェントとZDNet間のレスポンスタイムを計測することが可能という。
 |
| Webトレースの計測結果の詳細画面 |
ここではTopazエージェントからSBPまでのホップごとのレスポンスタイムを表示している。これを確認することにより，ネットワーク上のどこがボトルネックになっているかを見きわめることが可能だ。
「結論から言えば，今回の計測結果ではネットワークに特に大きな問題は見つからなかった。ここで示す例は計測期間中のある1時点（3月26日の9時33分）に発生した現象であり，それ以外のほとんどの時間帯でネットワークは非常に快適だった」（福田氏）
しいて言えば，まず最初のボトルネックとして，Topazエージェント（マーキュリーオフィス）からインターネットに出る部分（グラフ中のホップ1と2の間）が挙げられる。ホップ1までは10ミリ秒以下だったレスポンスタイムが，ホップ2でいきなり656ミリ秒になっている。
次のボトルネックはSBPが接続しているネットワークプロバイダーにある（グラフ中のホップ7とホップ8の間）。ここでグラフが約100ミリ秒かかっているのが分かる。
「Webサイトを運用する側にとって，ネットワーク（特にインターネット部分）の問題は非常に厄介だ。サイト内の問題であれば自ら各サーバ，アプリケーションの状態を確認して調査を行うこともできるが，ネットワークに関しては自分の管理下になく，誰もパフォーマンスを保証しない部分だからだ」（福田氏）
TopazのWebトレース機能は，ネットワーク上の問題がどこにあるのかをより明確にし，ネットワークのパフォーマンス管理を容易にするのに非常に有効な手段になるという。
パフォーマンス監視結果の結論
「今回の結果では，ZDNetのWebサイトは，お昼の12時台に大幅にレスポンスが悪化することが分かった。この原因は，接続時間が非常に長くなっているためだ。しかし，サーバ処理時間はこの時間帯でも悪くなっていないことから，Webサーバの接続要求処理能力を強化することでレスポンスタイムを大きく改善することが期待できる」（福田氏）
この結果を受けて……，というわけではないのだが，現在ZDNetでは，サーバ環境，ネットワーク環境の強化およびWebサイトの全面リニューアル（一部リニューアル済み）を進めている。これにより，お昼休みのレスポンスも改善されると思うので，読者の皆さまには，もう少しの辛抱をお願いします。
関連リンク
[山下竜大 ，ITmedia]
