特集：ネットワークトラブルを解決する

レスポンスの悪いネットワークシステム
どう検証し、解決していくか？

西村 稔
ネットマークス
2000/9/14

3. 遅延の構成要素

　ここで、アプリケーションのレスポンスがどのように構成されており、どのような観点でこれを評価していくべきかを考えてみよう。

　アプリケーションを操作する“ユーザー”にとってのレスポンス時間は、ある操作を開始してからその結果が得られるまでの時間である。ここで、このレスポンス時間は、大きく分類すると図4に示すようにクライントの遅延、サーバの遅延、およびネットワークの遅延に分けることができる。クライアントやサーバの遅延はネットワークの構成にはほとんど依存せず、クライアントとサーバ間のネットワークが高速であろうと低速であろうとほぼ同じ遅延が発生するものとなる。また、ネットワークの遅延は、通信フレームがネットワーク機器やメディア等を通過する時間が積算されて全体の遅延を構成している。

図4　レスポンスタイムの構成要素

　ここで、アプリケーションのレスポンスを改善することを目的としてネットワークの増強を考えた場合、クライアント／サーバ／ネットワークの遅延がどのような割合になっているかで、その対応方法は異なってくる。

　図5に同じレスポンス時間を要する2つのアプリケーションについて、遅延の割合を表したグラフを示す。アプリAはレスポンス時間の9割以上をクライアントとサーバの遅延で占めており、アプリBはネットワーク遅延が7割以上を占めるものとなっている。ここで、ネットワークを高速化した場合、2つのアプリはどのようなレスポンスを示すだろうか？

図5　2種類のアプリケーションのレスポンスタイムにおける遅延の割合

　まず、アプリAはレスポンスの改善はほとんど期待できないだろう。これは、ネットワーク遅延の占める割合が小さく、ネットワークがいかに高速化されようとも、アプリケーション全体のレスポンスには大きな影響がないからである。アプリAのレスポンスを改善するためには、ネットワークではなくサーバやクライアントの内部処理を検討するべきである。

　逆に、アプリBであればネットワーク遅延の割合が多いため、ネットワークが高速化されてネットワーク遅延が改善されれば、アプリケーション全体のレスポンス改善につながることが大いに期待できる。

　このように、レスポンスを改善するためには、遅延の構成要素によってその対応は異なってくる。もし、この見極めを誤ったならば、上記のアプリAのように本来はクライアントとサーバの内部処理を改善しなくてはいけないのに、ネットワークの高速化のみを実施してしまい、結局レスポンスは改善されない、といったむだな投資をしてしまう危険性があるのである。

Index
特集：ネットワークトラブルを解決する
	1. ネットワークのライフサイクル
	2. ネットワーク構築の失敗事例 　事例1：耐えられないレスポンス 　事例2：改善されないレスポンス
	3. 遅延の構成要素
	4. トラフィックの評価・検証方法（1） 　-トラフィックを「量」で評価 　-トラフィックを「質」で評価
	5. トラフィックの評価・検証方法（2） 　-ネットワークを「レスポンス」で評価 　-アプリケーションの通信形態を検証

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）