[1]　WEBのアクセス遅延の見える化
[2]　WEBサーバにより、オーバーヘッドの遅延差あり
[3]　EECの試験自体のパケットキャプチャーを実施
[4]　遅延の原因で、NWの帯域が足りないのか、WEBサーバに問題があるのかの切り分け
[5]　まとめ

１．WEBのアクセス遅延の見える化　　　テストトライアルにJump new

　最近のアプリケーションシステムは、WWWを利用したケースが増えております。
　アプリに近いレベルの試験（ｕｒｌ、ｗｇｅｔ）を行うことにより、通常の死活監視、ポート監視では分からない、お客さまのストレスを見える化します。

システム構成


ポート監視の例 あるＷＷＷサーバへの試験結果。 １０月１３日


ｕｒｌ監視（ｗｇｅｔ）の試験結果。 １０月１３日


　　　　　　　　　　　　凡例　青色：普通　緑：少し遅い　紫：遅い　赤：timeout

上記の表、グラフのとおり、
・ポート監視では、異常は発見できません。
・ｕｒｌ監視（ｗｇｅｔ）では、実際にＷＥＢサーバの情報を取ってくることにより、異常があることが分かります。
（０バイトの情報を入手するオプションコマンドを利用）
⇒ 単なるｐｉｎｇ監視、ポート監視に比べて、ｕｒｌ監視（ｗｇｅｔ）については、より、お客さまに使用の際のストレス状況を把握することができます。

２．WEBサーバにより、オーバーヘッドの遅延差あり

　WEBサーバの設置環境、アーキテクチャーによって、Basicなレスポンスにも違いがあります。
　次のように、EEC(End to End to Cheker)を用いて、３つのWebサーバに試験を行うことにより違いが明確になります。
　試験の環境は、次の図に示す通りです。クローズのネットワークにおいて、ＤＣ(Data Center）に設置してある３つのWebサーバに対して試験を行います。
【試験構成】



　ある日の試験結果を次に示します。


　一番シンプルなWEBアクセスの試験を行っています。同じWEBサーバですが、レスポンスタイムに違いがあることが分かります。
　WEBアクセスの場合、簡単な試験のレスポンスが、200ms や 300ms になっても一概に「体感で遅い」と感じることはありません。
しかしながら、ある程度遅延が大きくなってしまうと、エンドユーザでの使い勝手が悪くなりますので、シビアな監視が必要です。

３．EECの試験自体のパケットキャプチャーを実施

　それでは、次に簡単な試験を行った場合のこの３つのサーバのパケットの動きについて見ていきましょう。
　（具体的な試験コマンド wget --spider http://WEB-S_A/ ）

　この簡単な試験では、クライアントとサーバ間で、10パケットのやり取りをしています。
３つのサーバのパケットキャプチャの結果を次に示します。

　最初に試験端末（EEC）より、パケットが発出され、被試験WEBサーバから応答があり、パケットのやり取りを行います。




　まず、★印に注目して下さい。
　　WEB-S A ：0.009896
　　WEB-S B ：0.011011
　　WEB-S C ：0.009905

試験機器が、被試験WEBサーバにコネクションを張りに行き、その応答が★印の時間になります。
３つのサーバともほとんど差がありません。１行目と２行目は、通常のping試験（ping試験は、２パケットのやりとり）と同様の結果となります。

　それでは、①、②に注目して下さい。サーバからの応答に時間がかかっていることが分かります。
　サーバのアーキテクチャーの違いにより、この差が生じます。

４．遅延の原因で、NWの帯域が足りないのか、WEBサーバに問題があるのかの切り分け

　「３．EECの試験自体のパケットキャプチャーを実施」で行った試験結果より、ネットワーク（帯域、間に入る装置も含め）に問題があるのか、WEBサーバに問題があるかの大まかな把握ができます。

【ネットワーク（間に入る装置を含め）に原因があると考えられる場合】
　「３．」で示した、★印のレスポンスが速い場合は、ネットワーク的には、遅延なく処理を行っていることが分かります。
　WEB−S Bに注目して下さい。


　ネットワークの帯域不足の場合は、★印のところで遅延が発生します。他の時間帯、他のWEBサーバと比較することにより明確になります。


【WEBサーバにに原因があると考えられる場合】
　「３．」で示した、①のように、あるパケットの応答が遅くなる場合があります。
　WEB−S B に注目して下さい。


　本例では、①が、386ms 程度ですので、若干遅いぐらいですが、サーバにアクセスが集中してくると、この値が長くなってくることがあります。
第二パケットのレスポンス（★）が速く、①の部分のレスポンスが遅い場合は、
　 ネットワーク関連ではなく、サーバに原因がある可能性が高くなります。
　アクセスが集中し待ち状態になる等、サーバインフラに原因がある可能性が高いと考えられます。

　次の例は、ある財団のサイトです。「WEBのアクセスが遅い」との問い合わせがありましたので、調査した結果です。
このサイトは、httpsのみの運用になっておりますので、https の簡単な試験を行った例です。
この試験の場合は、次に示すように、試験機器とWEBサーバの間で、21パケットのやりとりを行っています。



　まず、★印の所に注目して下さい。約20ms と 速いレスポンスとなっています。これは、ping の試験結果とほぼ同じです。
　次に、①、②、③に注目して下さい。いづれも、WEBサーバからの応答で遅くなっております。

　このような場合には、ネットワーク（帯域）側と言うよりも、サーバ側の原因で遅延が発生している可能性が高くなります。

５．まとめ

　本ページでは、WEBサーバの遅延の原因究明方法について記述しました。
　EECを用いることにより、
　　・ネットワーク側に原因がある。
　　・サーバ側に原因がある。
　のおおよその切り分けができます。

　WEBは頻繁に利用されることが多くなり、単なるプロセス監視、ping 監視、port 監視では、エンドユーザの使い勝手の良し悪しが分かりません。
良い時のデータと、悪いときのデータを把握し、「お客さまの不満の限界値」を超えているのか、超えていないのかを常に見ていく必要があります。

遅延に関するお客さまの不満の限界値へリンク