Webアプリケーションのレスポンスタイムがよくない場合、問題を解析するにあたり、以下のようなことをやってみたりすると思います。
ところが、サーバアプリケーションの処理は、0.5秒で完了しているのに、ブラウザへの表示処理が終るまでには10秒以上かかるということになると、話はちょっと違ってきます。 こういったケースでの、次なる一手はどうすべきでしょうか？
インターネット接続の場合は、ネットワークトラフィックの問題に起因することも考えられますが、LANで接続されている場合には、また別のところにボトルネックが潜んでいる可能性が高くなります。 最近は、Ajaxを使ったRichクライアント型のアプリケーションが増えてきていますが、そこで実装されるJavaScriptのコーディングやHTML文書の構造も複雑化しており、パフォーマンスに与えるインパクトが無視できないものになっています。
そういったときに、問題を切り分けるための手段の一つとして、ネットワークモニタリングが有効です。取得されるデータには、タイムスタンプが記録されるため、クライアントからリクエストが送信され、サーバからレスポンスを受信するまでの時間を正確に知ることができ、ボトルネック箇所を絞り込みやすくなります。このときに、サーバとクライアントの時刻を合わせておくことが肝心です。 Webアプリケーションの場合には、以下に示す2つのレベルのモニタリングがあります。
パフォーマンスの問題などを、外見だけで調査しようとしても限界がありますし、視点を変えて解析してみることで、今まで見えなかったものが見えてくる場合もあります。
もしも、興味がある方は、とりあえず自分が開発しているWebアプリケーションで、どんな情報が流れているのか、モニタリングしてみてください。まず、問題発生時の状態と比較するために、正常時にどうなっているかを把握しておくことは大事ですし、見ること自体がHTTPやTCP/IPの勉強にもなると思います。
ご参考までに、以下に、Windows環境で利用可能なソフトウェアを挙げておきます。
- ストップウォッチで、submitしてから画面表示動作が完了するまでの時間を測定する。
- サーバ上のログ(HTTPアクセスログ、アプリケーションが出力するログなど)を見る。
ところが、サーバアプリケーションの処理は、0.5秒で完了しているのに、ブラウザへの表示処理が終るまでには10秒以上かかるということになると、話はちょっと違ってきます。 こういったケースでの、次なる一手はどうすべきでしょうか？
インターネット接続の場合は、ネットワークトラフィックの問題に起因することも考えられますが、LANで接続されている場合には、また別のところにボトルネックが潜んでいる可能性が高くなります。 最近は、Ajaxを使ったRichクライアント型のアプリケーションが増えてきていますが、そこで実装されるJavaScriptのコーディングやHTML文書の構造も複雑化しており、パフォーマンスに与えるインパクトが無視できないものになっています。
そういったときに、問題を切り分けるための手段の一つとして、ネットワークモニタリングが有効です。取得されるデータには、タイムスタンプが記録されるため、クライアントからリクエストが送信され、サーバからレスポンスを受信するまでの時間を正確に知ることができ、ボトルネック箇所を絞り込みやすくなります。このときに、サーバとクライアントの時刻を合わせておくことが肝心です。 Webアプリケーションの場合には、以下に示す2つのレベルのモニタリングがあります。
- HTTPレベルのモニタリング
デバッグ用のHTTP Proxyを使って、HTTP リクエスト/レスポンス電文をキャプチャリングする。キャプチャリングデータには、余分な制御電文などは含まれず、HTTP電文として、見やすいフォーマットに編集して表示してくれる。
但し、ブラウザのProxy設定を変更する必要があるので、それをしたくない人には不向きである。 - TCP/IPレベルのモニタリング
HTTPレベルでは問題が検知できない場合には、ネットワーク上を流れるパケットの単位でキャプチャリングする機能を持ったソフトウェア(Snifferとも呼ばれる)が必要になる。一般的なキャプチャリングソフトは、デフォルトでは、すべてのパケットをキャプチャリングしてしまうので、対象を必要なものだけに絞り込むためのフィルタリング機能が用意されている。
NICをターゲットにしてキャプチャリングを行うため、クライアントとサーバが同一ホスト内で稼働している場合には適用できない。
パフォーマンスの問題などを、外見だけで調査しようとしても限界がありますし、視点を変えて解析してみることで、今まで見えなかったものが見えてくる場合もあります。
もしも、興味がある方は、とりあえず自分が開発しているWebアプリケーションで、どんな情報が流れているのか、モニタリングしてみてください。まず、問題発生時の状態と比較するために、正常時にどうなっているかを把握しておくことは大事ですし、見ること自体がHTTPやTCP/IPの勉強にもなると思います。
ご参考までに、以下に、Windows環境で利用可能なソフトウェアを挙げておきます。
- デバッグ用HTTP Proxy
- パケットキャプチャリング
私のお薦めツールは NEGiES ですね
パケットキャプチャだけではなく「帯域制限」が可能です
データの通信「量」がボトルネックの場合、本番環境では遅いのだけど、テスト環境ではサクサク動作する、ということがあります
そのような場合は本番環境と同等に帯域制限されたテスト環境を作成しておくと、再現試験もできるし、問題修正後のモジュールの試験にも使用できます
ちなみにこの NEGiES。鴨が葱を背負ったアイコンがおちゃめです
情報をありがとうございます。
実際には、ISDNでアクセスするクライアントを考慮しなければならないこともあるので、NEGiESで提供されている帯域制限の機能は、そういうときなどに役立ちそうですね。
パケットモニタの画面も、TCPヘッダのサマリが、表形式で見やすく表示されるているところがいいですね。
パケットのデータの中身は見れないようなので、見たい場合は、ちょっと重たくなりますが、WiresharkやFiddler2と並行して動かせば可能ですね。