以下,本実施の形態について,図を用いて説明する。
図1は,本実施の形態による解析処理装置の機能構成例を示す図である。
図1に示す解析処理装置1は,情報システムの通信パケットを取り込み,通信パケットから情報システムの状態を分析する。解析処理装置1は,パケット受信部10,算出部11,データ量推測部12,予測部13,振り分け部14,メッセージ解析部15,蓄積部16を備える。
パケット受信部10は,ネットワークで接続されたコンピュータ間で送受信されるメッセージを所定の単位で分割したパケットを受信する。
算出部11は,過去に解析されたレスポンスメッセージのデータ量と解析に要した処理時間との履歴情報をもとに,レスポンスメッセージのデータ量と処理時間との関係式を算出する。この履歴情報は,リクエスト種別単位に蓄積されており,関係式は,リクエスト種別単位に算出される。
データ量推測部12は,リクエストメッセージを受信したときに,そのリクエスト種別に対応するレスポンスメッセージのデータ量を推測する。このデータ量の推測値としては,例えば最近の同じリクエスト種別に対する所定時間内または所定個数のレスポンスメッセージのデータ量の平均値などの統計データが用いられる。
予測部13は,データ量推測部12が推測したレスポンスメッセージのデータ量から,算出部11が算出した関係式を用いて,そのレスポンスメッセージのデータの解析処理時間を予測する。
振り分け部14は,予測した解析処理時間から,レスポンスメッセージのデータを解析するメッセージ解析部15の一つを選択し,該メッセージ解析部15にレスポンスメッセージのデータの解析処理を振り分ける。このとき,振り分け部14は,各メッセージ解析部15a,15b,... の解析処理時間が全体として平均化するように,解析処理を振り分ける。
メッセージ解析部15a,15b,... は,それぞれ制御部17a,17b,... ,すなわちマルチプロセッサにおける個々のプロセッサで動作し,振り分けられたメッセージの解析処理を実行する。メッセージ解析部15は,ネットワークで接続されたコンピュータ間で送受信される通信パケットから組み立てられるメッセージの解析を行う。
蓄積部16a,16b,... は,それぞれメッセージ解析部15a,15b,... が解析したレスポンスメッセージのデータ量と解析に要した処理時間とを,リクエスト種別単位に蓄積する。この履歴情報は,算出部11によって参照される。
算出部11が関係式の算出に用いるメッセージのデータ量は,レスポンスメッセージのデータ量である。以下,レスポンスメッセージのデータ量を,レスポンスデータ量とも呼ぶ。データ量推測部12が推測するメッセージのデータ量も,レスポンスデータ量である。これは,一般にリクエストメッセージのデータ量に比べてレスポンスメッセージのデータ量の方が多いので,解析処理時間の負荷はレスポンスデータの方が大きくなるからである。
図2は,本実施の形態による解析処理装置が用いられる情報システムの例を示す図である。
図2に示す情報システムでは,複数のコンピュータ3(3a,3b,3c,... )がネットワーク2で接続され,複数のコンピュータ3間でメッセージが送受信される。メッセージは,所定の単位でパケットに分割され,各パケットのヘッダに含まれる宛先情報によって,スイッチ4を介して通信先のコンピュータ3に送られる。パケットとは,通信モデルの一つであるTCP/IP(Transmission Control Protcol/Internet Protocol)モデルの中のインターネットレイヤでの送信単位である。
メッセージには,あるコンピュータ3に対して何らかの処理を要求するリクエストメッセージと,処理要求を受けたコンピュータ3が処理結果として応答するレスポンスメッセージとがある。
解析処理装置1は,スイッチ4のミラーリング機能を用いて,各コンピュータ3間で送受信されるパケットを受信し,受信したパケットからメッセージを再構成し,そのメッセージを解析することにより,情報システムの状態を分析する。すなわち,解析処理装置1は,コンピュータ3間で送受信されるリクエストメッセージ,レスポンスメッセージ等を監視し,分析することにより,通信しているコンピュータ3同士の稼働状態,通信状態等を把握することができる。
解析対象となるメッセージのデータ量は膨大であるため,解析処理装置1は,マルチプロセッサ環境でメッセージ解析処理の負荷分散を行っている。このとき,解析処理の負荷が均等になるように,各プロセッサに各メッセージの受信パケットを振り分ける必要がある。本実施の形態の技術では,メッセージ解析処理のためのパケットの振り分けが,各プロセッサにおける処理時間ができるだけ均等になるように行われる。
本実施の形態の技術をさらに詳しく説明する。
メッセージ解析処理は,リクエスト種別ごとに異なり,データ量と処理時間とが比例するものもあれば,処理時間が一定のものもあり,処理時間のバラツキが存在する。このバラツキを解消するために,算出部11は,リクエストのメッセージ解析処理を行いながら,リクエスト種別単位にレスポンスデータ量と処理時間との近似関係式を算出する。近似関係式は,例えば最小二乗法などの周知の分析手法を用いて算出することができる。
図3は,リクエスト種別ごとのレスポンスデータ量と処理時間との関係の例を示す図である。
図3(A)は,リクエスト種別が,例えば,電子掲示板に投稿するなどの「POST URL1」である場合の例を示す。また,図3(B)は,リクエスト種別が,例えば,未読メールを読み込むような「GET URL2」である場合の例を示す。また,図3(C)は,リクエスト種別が,例えば,画像データを取得する「GET URL3」である場合の例を示す。
例えば,図3(A)に示すように,同じリクエスト種別,同じレスポンスデータ量であっても,メッセージ解析の処理時間には,ある程度のバラツキが生じる。このことは,図3(B)や図3(C)の例についても同様である。図3において,楕円は,同じリクエスト種別のメッセージに対する処理において,メッセージごとのレスポンスデータ量と処理時間との関係のバラツキを表す。
また,例えば,図3(A)に示すリクエスト種別が「POST URL1」である場合と,図3(B)に示すリクエスト種別が「GET URL2」である場合には,傾き等に違いはあるが,レスポンスデータ量と処理時間とが比例する傾向にある。一方,図3(C)に示すリクエスト種別が「GET URL3」である場合には,処理時間がほぼ一定となっている。一般に画像データに対するレスポンスデータ量は一定であり,解析の処理時間も一定となる。
このように,レスポンスデータ量と処理時間との関係には,バラツキはあっても,リクエスト種別ごとの傾向がある。
そこで,図3に示すようなリクエスト種別ごとのレスポンスデータ量と処理時間との関係をつかむために,算出部11は,各蓄積部16a,16b,... が蓄積した履歴情報を利用して,近似関係式を算出する。各蓄積部16a,16b,... は,メッセージ解析部15a,15b,... が実際にメッセージ解析処理を実行した結果のレスポンスデータ量と処理時間とを,リクエスト種別ごとに記憶装置に蓄積しておく。
図4は,時間推移によるレスポンスデータ量の変化の例を示す図である。
図4(A)は,リクエスト種別が,例えば,電子掲示板に投稿するなどの「POST URL1」である場合の例を示す。また,図4(B)は,リクエスト種別が,例えば,未読メールを読み込むような「GET URL2」である場合の例を示す。また,図4(C)は,リクエスト種別が,例えば,画像データを取得する「GET URL3」である場合の例を示す。
動的レスポンスデータは,時間推移とともに変化する。例えば,掲示板などのリスト構造の場合には,図4(A)に示すように,時間が経過するに従って,徐々にレスポンスデータ量が増加するケースがある。また,例えば,メールの未読表示などの場合には,図4(B)に示すように,時間の流れとともに,レスポンスデータ量が増えたり減ったりするケースがある。画像データ表示などの場合には,図4(C)に示すように,レスポンスデータ量がほぼ一定であるケースが多い。
新しいレスポンスメッセージを解析処理するにあたって,そのレスポンスデータ量を推測する場合,どのケースでもレスポンスデータ量は直後のデータ量に近い。このため,データ量推測部12は,例えば,最近のある一定時間内のレスポンスデータ量の平均から,これから受信するレスポンスデータ量を推測する。一定時間内にレスポンスデータがない場合には,一定個数のレスポンスデータ量の平均から,これから受信するレスポンスデータ量を推測するようにしてもよい。
なお,レスポンスデータ量と処理時間とのバラツキを比較した場合,処理時間には,システム処理などの,メッセージ解析処理以外の処理にも同時にCPUが使われるケースも,含まれていることが考えられる。そこで,予測部13が新しいレスポンスデータの解析処理時間を予測する場合,履歴情報の処理時間を直接指標とするよりも,レスポンスデータ量を指標としたほうがバラツキが少ないと考えられる。
つまり,予測部13は,最近のある一定時間のレスポンスデータ量の平均を求めた後に,近似関係式から処理時間を求める方が,正確な処理時間を予測することが可能になる。その結果,振り分け部14は,リクエストメッセージを解析した時点で,レスポンスデータ解析の処理量にバラツキがあっても均等にCPUリソースが用いられるように,レスポンスデータの振り分け先CPUを決めることができる。すなわち,予測部13は,データ量推測部12が推測したレスポンスデータ量をもとに処理時間を予測し,求めた処理時間で振り分け先CPUを決定する。
以上の処理によって,バラツキのあるレスポンスメッセージ解析処理の効率的な負荷分散を実現することができる。
図5は,本実施の形態による解析処理装置のハードウェア構成例を示す図である。
解析処理装置1は,複数のCPU20,すなわちCPU(#0)20a,CPU(#1)20b,CPU(#2)20cを有するマルチプロセッサシステムとなっている。なお,図5に示す例ではCPU20の数は3つであるが,CPU20の数は2つ以上であればいくつでもよい。
解析処理装置1は,メモリ21,ハードディスクや半導体記憶装置などの記憶装置23,入力装置26が接続される入出力I/F(Interface )24,出力装置27が接続される入出力I/F25を備える。また,解析処理装置1は,ネットワークに接続するためのNIC(Network Interface Card)28を備える。NIC28は,スイッチ4のミラーポートに接続されている。スイッチ4は,監視対象のコンピュータ通信の通信路をスイッチングしており,受信したパケットをミラーリング接続でNIC28に伝達する。
記憶装置23には,パケット受信プログラム31,メッセージ解析プログラム32を含む解析処理アプリケーション30およびオペレーティングシステム33が格納されている。オペレーティングシステム33,解析処理アプリケーション30は,起動時にメモリ21にロードされ,CPU(#0)20a等のコンピュータにメッセージ解析のための処理を実行させる。
特に,パケット受信プログラム31は,NIC28に到達したパケットを,NIC28のプロミスキャスモードを用いてオペレーティングシステム33を経由して取り込む処理を,コンピュータに実行させる。また,メッセージ解析プログラム32は,パケット受信プログラム31によって受信したパケットで構成されるメッセージを解析する処理を,コンピュータに実行させる。プロミスキャスモードとは,宛先が自装置宛でないパケットも受信するモードである。
パケット受信プログラム31は,パケットを受信して,そのパケットについてメッセージ解析を行うCPU20の一つに割り当てる処理を,例えばCPU(#0)20aに実行させるプログラムである。メッセージ解析プログラム32は,パケットを割り当てられたCPU20,例えばCPU(#1)20bやCPU(#2)20cで実行される。
また,記憶装置23またはメモリ21には,メッセージ解析処理に用いるコネクション情報テーブル34,振り分け用テーブル35,履歴情報テーブル36,CPU予定処理時間テーブル37が設けられる。
メモリ21のバッファ22aは,例えばCPU(#1)20bが使用するバッファであり,バッファ22bは,CPU(#2)20cが使用するバッファである。受信パケットは,これらのバッファ22a,22bに格納され,各CPU(#1)20b,CPU(#2)20cに振り分けられる。
図6は,本実施の形態によるコネクション情報テーブルの一例を示す図である。
図6に示すコネクション情報テーブル34は,接続先IPアドレス,接続先ポート番号,接続元IPアドレス,接続元ポート番号,コネクション番号のデータ項目を持つ。各TCPコネクションごとに,接続先IPアドレスの項目には,接続先のIPアドレスが格納される。接続先ポート番号の項目には,接続先のポート番号が格納される。接続元IPアドレスの項目には,接続元のIPアドレスが格納される。接続元ポート番号の項目には,接続元のポート番号が格納される。コネクション番号の項目には,コネクションを一意に識別するコネクション番号が格納される。
なお,「接続先」とは,コネクションを確立する際に,接続を要求された側をいう。「接続元」とは,コネクションを確立する際に,接続を要求した側をいう。以下,接続先IPアドレス,接続先ポート番号,接続元IPアドレス,接続元ポート番号,コネクション番号を含む1組の情報をコネクション情報と呼ぶ。
図7は,本実施の形態による履歴情報テーブルの一例を示す図である。
図7に示す履歴情報テーブル36には,リクエスト種別単位に,実際に解析されたレスポンスデータ量と,解析処理に要した処理時間と,解析処理の開始時刻の履歴情報が格納される。図7に示す履歴情報テーブル36において,レスポンスデータ量の単位はバイト[B]であり,処理時間の単位は秒[sec]である。
ここでは,リクエスト種別としてHTTPリクエストの例を示したが,リクエスト種別は,処理要求のメッセージの種類を示す情報であればよく,HTTPリクエストに限られない。ちなみに,「SELECT TABLE1」は,SQLによる関係データベースのテーブル検索要求である。
図8は,本実施の形態によるCPU予定処理時間テーブルの一例を示す図である。
図8に示すCPU予定処理時間テーブル37は,CPU20単位に予定処理時間が格納されるテーブルである。図8に示すCPU予定処理時間テーブル37において,CPU番号は,CPU20を特定する識別情報である。図8に示すCPU予定処理時間テーブル37には,各CPU20に対して割り当てられたメッセージ解析対象となるコネクションのコネクション番号と,その予定処理時間とが格納され,また,各CPU20の予定処理時間の合計値が格納される。図8に示すCPU予定処理時間テーブル37において,予定処理時間と予定処理時間合計の単位は秒[sec]である。
図9は,本実施の形態による振り分け用テーブルの一例を示す図である。
図9に示す振り分け用テーブル35は,コネクション番号ごとに,振り分け先CPU20を示す振り分け先CPU番号と,リクエスト種別との情報が格納されるテーブルである。
図10は,パケットの構成を示す図である。
パケットは,図10(A)に示すように,IPヘッダ,TCPヘッダ,TCPデータを含む。
IPヘッダは,図10(B)に示すようなデータ構造を持つ。IPヘッダには,バージョン,ヘッダ長,サービスタイプ,データグラム長,識別子,各種のフラグ,フラグメントオフセット,生存時間,プロトコル,ヘッダチェックサム,送信元IPアドレス,送信先IPアドレス,オプション,パディングの項目が格納される。
TCPヘッダは,図10(C)に示すようなデータ構造を持つ。TCPヘッダには,送信元ポート番号,送信先ポート番号,シーケンス番号,確認応答番号,ヘッダ長,予約ビット,フラグ,ウィンドウサイズ,チェックサム,緊急ポインタ,オプション,パディングの項目が格納される。
図11は,TCPコネクションの接続シーケンスの一例を示す図である。
ここでは,接続シーケンスの例として,スリーウェイハンドシェイクによるTCPコネクションの確立について説明する。
図11において,最初に,接続を要求する側のコンピュータすなわちクライアントは,接続を要求される側のコンピュータすなわちサーバに,TCPヘッダ内のSYNを示すフラグが立ったSYNパケットを送信する。サーバは,TCPヘッダ内でSYNフラグとACKフラグが立ったSYN ACKパケットをクライアントへ送信する。クライアントは,ACKフラグが立ったACKパケットをサーバへ送る。これにより,クライアントとサーバの間のコネクションが確立し,コネクション接続状態となる。なお,接続を要求する側から接続を要求される側への接続方向を「上り」といい,その反対方向を「下り」という。
TCPコネクションの切断は,次のように行われる。TCPコネクションを切断しようとする側から相手側に,TCPヘッダ内のFINを示すフラグが立ったFINパケットを送信する。これに対して,相手側は,TCPコネクションを切断しようとする側にACKパケットを送信し,片方向のコネクションが開放される。さらに,相手側は,TCPコネクションを切断しようとする側にFINパケットを送信し,TCPコネクションを切断しようとする側は,相手側にACKパケットを返信する。これにより,もう片方向のコネクションも開放される。
図12は,本実施の形態のマルチプロセッサによるメッセージ単位でのパケットの分散処理シーケンスを示す図である。
図11で説明したコネクション接続状態において送受信されるメッセージ単位でのパケットを,マルチプロセッサのCPU(#0)20a,CPU(#1)20b,CPU(#2)20cが,次のように処理する。
CPU(#0)20aは,NIC28から送られたパケットを受信すると(処理50),パケットのヘッダ情報を参照することによりコネクションを解析し(処理51),パケットの送信方向を識別する。CPU(#0)20aは,パケットの送信方向が「上り」であるか「下り」であるかを判定する(処理52)。パケットの送信方向が「上り」であれば(処理52の上り),CPU(#0)20aは,処理53〜処理57を実行する。パケットの送信方向が「下り」であれば(処理52の下り),CPU(#0)20aは,処理58を実行する。
パケットの送信方向が「上り」である場合(処理52の上り),CPU(#0)20aは,まず,そのパケットを含んで構成されるリクエストメッセージの組み立てを行い,リクエスト内容を解析する(処理53)。CPU(#0)20aは,リクエスト内容の解析によって,要求の種類を示すリクエスト種別を得る。CPU(#0)20aは,履歴情報テーブル36からそのリクエスト種別に対応する履歴情報を読み込み,過去に蓄積されたレスポンスデータ量と処理時間とから,これらの近似関係式を算出する(処理54)。
次に,CPU(#0)20aは,同じく履歴情報テーブル36から得た最近のレスポンスデータ量の平均値を算出する(処理55)。CPU(#0)20aは,算出した平均値から,現在のリクエストメッセージに対するレスポンスメッセージのレスポンスデータ量を推測する。CPU(#0)20aは,推測したレスポンスデータ量に対して解析に要する処理時間を,処理54で算出した近似関係式を用いて算出する(処理56)。
CPU(#0)20aは,算出した処理時間から振り分け先のCPU20を決定し,振り分け用テーブル35に設定する(処理57)。すなわち,CPU(#0)20aは,図9に示す振り分け用テーブル35に,コネクション番号と,振り分け先CPU番号と,リクエスト種別を設定する。CPU(#0)20aが振り分け先のCPU20を決定する際には,後に詳しく説明するように,図8に示すCPU予定処理時間テーブル37を参照し,各CPU20の予定処理時間の合計値が均等になるように,振り分け先のCPUを選択する。
パケットの送信方向が「下り」である場合(処理52の下り),そのパケットはレスポンスメッセージのパケットである。このとき,CPU(#0)20aは,振り分け用テーブル35を参照して,そのパケットを振り分け先のCPU20,ここではCPU(#1)20bまたはCPU(#2)20cに振り分ける(処理58)。
各CPU(#1)20b,CPU(#2)20cは,振り分けられたパケットからレスポンスメッセージを組み立てて,レスポンスメッセージを解析する(処理60,60’)。各CPU(#1)20b,CPU(#2)20cが,どのような解析処理を行うかについては任意であり,本実施の形態の要旨ではないので,ここでの解析処理の内容についての説明は割愛する。
各CPU(#1)20b,CPU(#2)20cは,レスポンスメッセージの解析処理にともない,レスポンスデータ量を取得するともに(処理61,61’),処理時間を計測する(処理62,62’)。各CPU(#1)20b,CPU(#2)20cは,それらの結果をもとに,履歴情報テーブル36のデータを更新する(処理63,63’)。
図13,図14は,本実施の形態のCPU(#0)によるコネクション解析処理フローチャートである。
CPU(#0)20aは,NIC28から送られたパケットを受信したかを判定する(ステップS10)。
パケットを受信した場合には(ステップS10の真),CPU(#0)20aは,パケットのヘッダ情報を参照することにより,コネクション情報を取得する(ステップS11)。コネクション情報は,接続先IPアドレス,接続先ポート番号,接続元IPアドレス,接続元ポート番号等の情報である。
CPU(#0)20aは,ステップS11で取得したコネクション情報をもとに,コネクション情報テーブル34を検索する(ステップS12)。CPU(#0)20aは,コネクション情報テーブル34から,ステップS11で取得したコネクション情報に一致するコネクション情報が検出されたかを判定する(ステップS13)。一致するコネクション情報が検出された場合には(ステップS13の真),CPU(#0)20aは,ステップS14に進む。一致するコネクション情報が検出されなかった場合には(ステップS13の偽),CPU(#0)20aは,ステップS25に進む。
一致するコネクション情報が検出された場合(ステップS13の真),CPU(#0)20aは,コネクションの接続方向が上りであると特定する(ステップS14)。CPU(#0)20aは,受信した上りパケットからリクエストメッセージの組み立てを行う(ステップS15)。CPU(#0)20aは,リクエストメッセージを組み立てた後,リクエスト内容を解析する(ステップS16)。
リクエスト内容の解析とは,リクエストメッセージについて,プロトコルの種類ごとに解析を行うことにより,クライアントからサーバへの要求の種類を示すリクエスト種別と,要求に付随する設定値を示すリクエストパラメータを取り出す処理のことである。なお,リクエストパラメータが存在しない場合もある。
例えば,リクエスト種別とリクエストのパラメータは,HTTPプロトコルの場合(POST /cgi−bin/xxx.cgi? 名前1=値1&名前2=値2),リクエスト種別がメソッド(POST)+URL(/cgi−bin/xxx.cgi),リクエストのパラメータがCGIパラメータ(名前1=値1&名前2=値2)となる。また,リクエスト種別とリクエストのパラメータは,DBプロトコルの場合,例えば「SELECT * FROM table1 WHERE NAME=****」というようなSQL文を取り出したとすると,次のようになる。コマンド部分(SELECT * FROM table1)がリクエスト種別,リクエストのパラメータが引数(NAME=****)になる。
CPU(#0)20aは,履歴情報テーブル36に蓄積された“リクエスト種別単位のレスポンスデータ量と処理時間と時刻”の履歴情報から,過去の該当リクエスト種別のレスポンスデータ量と処理時間とを取得する(ステップS17)。CPU(#0)20aは,取得したレスポンスデータ量と処理時間とをもとに,最小二乗法などを用いて,レスポンスデータ量と処理時間との近似関係式を算出する(ステップS18)。
CPU(#0)20aは,例えば,現在時間から1分以内のレスポンスメッセージのデータ量を,履歴情報テーブル36から取得する(ステップS19)。なお,現在時間から1分以内のデータがない場合に,CPU(#0)20aが,新しい方から10個以内のレスポンスメッセージのデータ量を取得する,などの実施も可能である。CPU(#0)20aは,取得したレスポンスメッセージのデータ量の平均値を算出する(ステップS20)。CPU(#0)20aは,データ量の平均値から,ステップS18で算出した近似関係式を用いて,予定処理時間を求める(ステップS21)。
CPU(#0)20aは,予定処理時間を算出すると,CPU予定処理時間テーブル37からCPU20ごとの予定処理時間の合計値を検索し,最小の合計値のCPU番号を選択する(ステップS22)。CPU(#0)20aは,ステップS22で算出した予定処理時間を,CPU予定処理時間テーブル37における選択したCPU番号に対応させて,コネクション番号とともに保存する(ステップS23)。また,CPU(#0)20aは,CPU予定処理時間テーブル37における該当CPUの予定処理時間合計値に,予定処理時間を加算する(ステップS23)。
CPU(#0)20aは,振り分け用テーブル35の新しいエントリに,コネクション番号,振り分け先CPU番号およびリクエスト種別を格納し,振り分け用テーブル35を更新し(ステップS24),処理を終了する。
一致するコネクション情報が検出されなかった場合(ステップS13の偽),CPU(#0)20aは,取得したコネクション情報における接続先IPアドレスと接続元IPアドレスとを入れ替える(ステップS25)。また,CPU(#0)20aは,接続先ポート番号と接続元ポート番号とを入れ替える(ステップS25)。CPU(#0)20aは,ステップS25で接続先と接続元を入れ替えたコネクション情報を用いて,コネクション情報テーブル34を検索する(ステップS26)。
CPU(#0)20aは,ステップS26でコネクション情報テーブル34を検索した結果,該当するコネクション情報が検出されたかを判定する(ステップS27)。該当するコネクション情報が検出された場合には(ステップS27の真),CPU(#0)20aは,ステップS28に進む。該当するコネクション情報が検出されなかった場合には(ステップS27の偽),CPU(#0)20aは,ステップS32に進む。
該当するコネクション情報が検出された場合(ステップS27の真),CPU(#0)20aは,そのパケットを下りパケットと特定する(ステップS28)。CPU(#0)20aは,振り分け用テーブル35を参照する(ステップS29)。CPU(#0)20aは,振り分け用テーブル35中のコネクション番号から,振り分け先CPU番号とリクエスト種別を取得する(ステップS30)。CPU(#0)20aは,振り分け先CPU番号のCPU20に,下りパケットを,リクエスト種別とともに通知し(ステップS31),処理を終了する。
該当するコネクション情報が検出されなかった場合(ステップS27の偽),CPU(#0)20aは,受信パケットが上りパケットでも下りパケットでもないので,コネクション確立メッセージのパケットかどうかを判定する(ステップS32)。受信したパケットがコネクション確立メッセージのパケットである場合には(ステップS32の真),CPU(#0)20aは,ステップS33に進む。受信したパケットがコネクション確立メッセージのパケットでもない場合には(ステップS32の偽),CPU(#0)20aは,処理を終了する。
受信したパケットがコネクション確立メッセージのパケットである場合には(ステップS32の真),CPU(#0)20aは,コネクション接続の確認をする(ステップS33)。その後,CPU(#0)20aは,コネクション接続が確認されたコネクション情報を,コネクション情報テーブル34に設定し(ステップS34),処理を終了する。コネクション情報は,接続先IPアドレス,接続先ポート番号,接続元IPアドレス,接続元ポート番号,コネクション番号等である。
図15は,本実施の形態のCPU(#1)またはCPU(#2)によるレスポンスメッセージ解析処理フローチャートである。
図15に示すフローチャートは,受信パケットを振り分けられたCPU(#1)20bまたはCPU(#2)20cが,レスポンスメッセージ解析処理を実行する場合の例を示す。CPU(#1)20b,CPU(#2)20cは,受信パケットを振り分けられると,図15に示す処理を実行する。なお,以下では,CPU(#1)20bによる処理を例に説明を行うが,CPU(#2)20cについても同様である。
CPU(#1)20bは,受信パケットからレスポンスメッセージを組み立てる(ステップS40)。CPU(#1)20bは,組み立てたレスポンスメッセージの内容を解析する(ステップS41)。レスポンスメッセージの解析では,例えば,応答コードなどの情報が取得される。
CPU(#1)20bは,内容解析の対象となったレスポンスデータのデータ量を求める(ステップS42)。CPU(#1)20bは,このときの解析に要した処理時間の測定を行う(ステップS43)。
CPU(#1)20bは,通知されたリクエスト種別と求めた解析の処理時間とをもとに,リクエスト単位のレスポンスデータ量と処理時間と時刻の情報を,履歴情報テーブル36に新履歴データとして挿入し,履歴情報テーブル36を更新する(ステップS44)。
CPU(#1)20bは,CPU予定処理時間テーブル37から,CPU20単位の予定処理時間を読み出し,合計値から減算し,CPU予定処理時間テーブル37を更新する(ステップS45)。
以上説明した本実施の形態の解析処理装置1によれば,レスポンスデータ解析の処理量にバラツキがあっても,リクエスト種別を解析した時点で,均等にCPUリソースを用いるように,その後のレスポンスデータ解析の振り分け先CPU20を決めることができる。したがって,本実施の形態の解析処理装置1は,各CPU20への解析処理の振り分けを均等化することができる。これにより,解析処理装置1におけるCPUリソースの有効な利用が可能となる。
以上,本実施の形態について説明したが,本発明はその主旨の範囲において種々の変形が可能であることは当然である。