アプリケーションの遅延

アプリケーションの遅延

 日常の業務を行っていて、各種アプリケーションの応答速度が遅いと感じておられることはありませんか。

 アプリケーションの応答速度が遅いと、いらいらするだけでなく、注意力が散漫になりミスの原因にも繋がります。

 本ページでは、アプリケーションの遅延について、詳しく解説します。

 アプリケーションの遅延の要因は、次の2つに分類できます。

1.ネットワークインフラに起因するもの
2.ネットワークインフラ以外に起因するもの

”1”のネットワークインフラに起因するものについては、
  「 ネットワークの遅延のページ」も ご参照下さい。

 本ページでは、WANとLAN環境による違い、パケットのやりとりを見て遅延の原因を究明することについて詳しく説明します。

1.WAN環境におけるレスポンスについて

 アプリケーションの開発は、クラウド基盤を利用することも多くなりましたが、LAN環境で行った場合、注意する点があります。

アプリケーションの遅延:LAN環境のアプリケーションの開発

 LAN内の応答速度は、非常に速いため、クライアントとサーバの通信のやりとりが多いプログラムも少ないプログラムもレスポンスには余り影響されません。

アプリケーションの遅延:LAN環境のクライアント・ サーバ 間のやりとり


 LAN環境では、クライアントとサーバ間の応答速度が問題になりませんが、WAN環境においては、問題になってくる場合があります。

アプリケーションの遅延:WAN環境のクライアント・ サーバ 間のやりとり

 WANの場合、LANに比べると遅延が発生し、一回のやりとりの時間がかかってしまいますので、やりとりが多くなりますと、利用者が感じる遅延が非常に大きくなります。

 アプリケーション開発の場合、WAN環境の遅延を意識して基本設計を行う必要があります。

 アプリケーションの仕様上、やりとりが減らせない場合は、やりとりをまとめて処理をするような、WAN高速化商品等を導入するケースもあります。

2.クライアントとサーバのパケットのやりとりの実際

 クライアントとサーバの実際のパケットのやりとりを見るためクライアントにてパケットキャプチャを行いました。

アプリケーションの遅延:パケットキャプチャの場所

 次に、ping(ICMP)、80ポート、wget(WEBを実際に見に行く)のパケットについてみて行きます。

(1)ping(ICMP):死活監視

アプリケーションの遅延:pingのやりとり

<パケットの詳細>
11:18:06.266995 IP PC > Server: ICMP echo request, id 4448, seq 1
11:18:06.288856 IP Server > PC: ICMP echo reply, id 4448, seq 1, length 64

 1往復のパケットのやりとりとなっています。

(2)80ポート監視 :WEBサーバをアクセスするポート

アプリケーションの遅延:80ポート試験のやりとり

<パケットの詳細>
①11:40:18.561515 IP PC.55874 > Server.http: Flags [S], seq 1053017930,
 win 14600, options [mss 1460,sackOK,TS val 3302755297 ecr 0,nop,wscale 7], length 0

②11:40:18.583100 IP Server.http > PC.55874: Flags [S.], seq 1745710799, ack 1053017931,
 win 14480, options [mss 1300,sackOK,TS val 3421461054 ecr 3302755297,nop,wscale 6], length 0

③11:40:18.583127 IP PC.55874 > Server.http: Flags [.], ack 1,
 win 115, options [nop,nop,TS val 3302755319 ecr 3421461054], length 0

④11:40:18.583150 IP PC.55874 > Server.http: Flags [F.], seq 1, ack 1,
 win 115, options [nop,nop,TS val 3302755319 ecr 3421461054], length 0

⑤11:40:18.605197 IP Server.http > PC.55874: Flags [F.], seq 1, ack 2,
 win 227, options [nop,nop,TS val 3421461076 ecr 3302755319], length 0

⑥11:40:18.605216 IP PC.55874 > Server.http: Flags [.], ack 2,
 win 115, options [nop,nop,TS val 3302755341 ecr 3421461076], length 0

 クライアントから、SYN(コネクション確率要求)を行い、直ぐにFIN(コネクション解放要求)を行っています。
制御パケットのみになりますので、データ部のlengthは、全て 0 となっています。


(3)wget(--spiderオプション)の試験:実際にWEBページにアクセスしデータを取得する

アプリケーションの遅延:wget(--spiderオプション)のやりとり

<パケットの詳細>
①13:23:31.827018 IP PC.37595 > Server.http: Flags [S], seq 1913914691,
 win 14600, options [mss 1460,sackOK,TS val 3308948563 ecr 0,nop,wscale 7], length 0

②13:23:31.846538 IP Server.http > PC.37595: Flags [S.], seq 1660984565, ack 1913914692,
 win 14480, options [mss 1300,sackOK,TS val 3427654430 ecr 3308948563,nop,wscale 6], length 0

③13:23:31.846562 IP PC.37595 > Server.http: Flags [.], ack 1,
 win 115, options [nop,nop,TS val 3308948582 ecr 3427654430], length 0

④13:23:31.846756 IP PC.37595 > Server.http: Flags [P.], seq 1:115, ack 1,
 win 115, options [nop,nop,TS val 3308948582 ecr 3427654430], length 114

⑤13:23:31.866282 IP Server.http > PC.37595: Flags [.], ack 115,
 win 227, options [nop,nop,TS val 3427654450 ecr 3308948582], length 0

⑥13:23:31.868511 IP Server.http > PC.37595: Flags [P.], seq 1:239, ack 115,
 win 227, options [nop,nop,TS val 3427654452 ecr 3308948582], length 238

⑦13:23:31.868523 IP PC.37595 > Server.http: Flags [.], ack 239,
 win 123, options [nop,nop,TS val 3308948604 ecr 3427654452], length 0

⑧13:23:31.868531 IP Server.http > PC.37595: Flags [F.], seq 239, ack 115,
 win 227, options [nop,nop,TS val 3427654452 ecr 3308948582], length 0

⑨13:23:31.868921 IP PC.37595 > Server.http: Flags [F.], seq 115, ack 240,
 win 123, options [nop,nop,TS val 3308948604 ecr 3427654452], length 0

⑩13:23:31.887621 IP Server.http > PC.37595: Flags [.], ack 116,
win 227, options [nop,nop,TS val 3427654471 ecr 3308948604], length 0

 SYN(コネクション確率要求)パケット、FIN(コネクション解放要求)パケットの間に、データのやり取り部分があります。
④~⑦がデータのやりとり部分です。

3.WEBアクセスでレスポンスが遅い事例

 WEBアクセスで非常に遅い場合のクライアントとサーバのやりとりの例を示します。

アプリケーションの遅延:WEBアクセスが遅い例

WEBアクセスが遅い場合のやりとり

<処理が遅いと仮定した場合の解析>
図の青い丸と赤い丸の部分に注目して下さい。
青い丸の部分の値が、pingのレスポンスと変わらない場合は、データのやりとりにおいて遅延が発生している場合があります。

WWWサーバは、DB(データベース)サーバにアクセスし、DBサーバの結果を処理して、クライアント側に応答を返す場合もあります。

データのやりとりのパケットの中身を見ることによりどの部分で遅延が発生しているか推測することが可能です。

青い丸の部分が遅くなっている場合(ping値も同様に遅い)は、トラヒックが混雑して遅延が発生したり(回線帯域不足)、経由する機器、例えばFW(ファイヤーウォール)等のために遅延が発生している場合も考えられます。

参考: 「サーバインフラによるアプリケーションの遅延」のページ

参考: 「FW超え試験」のページ

4.アプリケーションの遅延(まとめ)

 アプリケーションの遅延は業務に大きな影響を及ぼします。

遅延の原因は、

1.ネットワークインフラに起因するものは、  

「ネットワークの遅延」のページに示したとおり、原因も多様です。


2.ネットワークインフラ以外に起因するものは、

 本ページで示したとおり、クライアントとサーバのパケットのやりとりを分析することにより遅延の原因を発見することができる場合があります。

 アプリケーションの遅延は、他にも要因があり、システムのトータル的なチェックが必要です。

  これまでのような機器の個別監視(死活監視等)から、「トータル監視(エンドユーザがストレス無く使えているかを見える化する)」が必要となってきます。

  トータル監視のページへ

  トータル監視の考え方で課題を解決した例(SalesForceの遅延)

  弊社保守サービス特徴

  お問合せ

a:1834 t:3 y:3

最新の更新 RSS  Valid XHTML 1.0 Transitional