(57)【特許請求の範囲】
【請求項１】
第１デバイスが処理を開始するステップと、前記処理を遂行するステップと、第２デバイスが前記処理を終了するステップと、を含むデータ処理方法におけるシステムパフォーマンスの測定方法であって、
ロギングデバイスが、前記処理の開始時に入力される入力データ、または、前記処理の開始により生成される開始通知データ、を受け取るステップと、
前記ロギングデバイスのシステムクロックを用いて、前記入力データまたは前記開始通知データの受け取り時刻を含む処理開始時データを生成するステップと、
前記ロギングデバイスが前記処理の終了により生成される終了通知データを受け取るステップと、
前記ロギングデバイスのシステムクロックを用いて、前記終了通知データの受け取り時刻を含む処理終了時データを生成するステップと、
前記処理開始時データおよび前記処理終了時データを比較して、前記処理に要した時間を算出するステップと、
を含むシステムパフォーマンスの測定方法。
【請求項２】
前記ロギングデバイスが、前記処理開始時データを記録媒体に記録するステップと、前記処理終了時データを前記記録媒体に記録するステップと、をさらに有する請求項１記載の測定方法。
【請求項３】
前記ロギングデバイスが、前記受け取った入力データを記録媒体に記録するステップをさらに有する請求項２記載の測定方法。
【請求項４】
前記開始通知データは、前記入力データを受け取り前記入力データを記録媒体に記録する他の入力ログデバイスから転送された前記入力データ、または、前記処理の開始により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の開始により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項１記載の測定方法。
【請求項５】
前記終了通知データは、前記第２デバイスからの前記入力データを含むメッセージ、または、前記処理の終了により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の終了により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項１記載の測定方法。
【請求項６】
前記処理開始時データには、前記入力データまたは前記開始通知データが含まれ、前記処理終了時データには、前記終了通知データが含まれ、
前記処理開始時データと前記処理終了時データとは、前記入力データに含まれる一部のデータ、または、前記変更に係るファイルの名称およびサイズ、または、前記ネットワーク上で捕捉されたメッセージ、のいずれかで関連付けられる請求項４または５記載の測定方法。
【請求項７】
前記開始通知データおよび終了通知データは、ＴＣＰまたはＵＤＰを適用して伝送される請求項１記載の測定方法。
【請求項８】
処理を開始する第１デバイスと、前記処理を遂行する手段と、前記処理を終了する第２デバイスと、前記処理の少なくとも開始または終了の時点を記録するロギングデバイスと、を含むデータ処理システムであって、前記ロギングデバイスには、
前記第１デバイスに入力される入力データ、または、前記処理の開始により生成される開始通知データを受け取る手段と、
前記ロギングデバイスのシステムクロックによる前記入力データまたは前記開始通知データの受け取り時刻を含む処理開始時データを生成する手段と、
前記処理の終了により生成される終了通知データを受け取る手段と、
前記ロギングデバイスのシステムクロックによる前記終了通知データの受け取り時刻を含む処理終了時データを生成する手段と、
を含むデータ処理システム。
【請求項９】
前記処理開始時データおよび前記処理終了時データを比較して、前記処理に要した時間を算出する手段をさらに含む請求項８記載のデータ処理システム。
【請求項１０】
前記処理開始時データを記録媒体に記録する手段と、前記処理終了時データを前記記録媒体に記録する手段と、前記受け取った入力データを記録媒体に記録する手段と、をさらに有する請求項８記載のデータ処理システム。
【請求項１１】
前記開始通知データは、前記入力データを受け取り前記入力データを記録媒体に記録する他の入力ログデバイスから転送された前記入力データ、または、前記処理の開始により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の開始により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項７記載のデータ処理システム。
【請求項１２】
前記終了通知データは、前記第２デバイスからの前記入力データを含むメッセージ、または、前記処理の終了により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の終了により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項８記載のデータ処理システム。
【請求項１３】
前記処理開始時データには、前記入力データまたは前記開始通知データが含まれ、前記処理終了時データには、前記終了通知データが含まれ、
前記処理開始時データと前記処理終了時データとは、前記入力データに含まれる一部のデータ、または、前記変更に係るファイルの名称およびサイズ、または、前記ネットワーク上で捕捉されたメッセージ、のいずれかで関連付けられる請求項１１または１２記載のデータ処理システム。
【請求項１４】
前記開始通知データおよび終了通知データは、ＴＣＰまたはＵＤＰを適用して伝送される請求項８記載のデータ処理システム。
【請求項１５】
第１デバイスへの入力データまたは前記第１デバイスから開始される処理の開始通知データを受け取る手段と、
前記入力データまたは前記開始通知データの受け取り時刻をそのシステムクロックにより判断し、前記受け取り時刻を含む処理開始時データを生成する手段と、
前記第１デバイスとは異なる第２デバイスによる前記処理の終了により生成される終了通知データを受け取る手段と、
前記終了通知データの受け取り時刻をそのシステムクロックにより判断し、前記受け取り時刻を含む処理終了時データを生成する手段と、
を含むデータロギングシステム。
【請求項１６】
前記処理開始時データを記録媒体に記録する手段と、前記処理終了時データを前記記録媒体に記録する手段と、前記受け取った入力データを記録媒体に記録する手段と、をさらに有する請求項１５記載のデータロギングシステム。
【請求項１７】
前記開始通知データは、前記入力データを受け取り前記入力データを記録媒体に記録する他の入力ログデバイスから転送された前記入力データ、または、前記処理の開始により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の開始により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項１５記載のデータロギングシステム。
【請求項１８】
前記終了通知データは、前記第２デバイスからの前記入力データを含むメッセージ、または、前記処理の終了により記録内容が変更された記録媒体内の前記変更に係るファイルの名称およびサイズ、または、前記処理の終了により生成されネットワーク上で捕捉されたメッセージ、のいずれかである請求項１５記載のデータロギングシステム。
【請求項１９】
前記処理開始時データには、前記入力データまたは前記開始通知データが含まれ、前記処理終了時データには、前記終了通知データが含まれ、
前記処理開始時データと前記処理終了時データとは、前記入力データに含まれる一部のデータ、または、前記変更に係るファイルの名称およびサイズ、または、前記ネットワーク上で捕捉されたメッセージ、のいずれかで関連付けられる請求項１７または１８記載のデータロギングシステム。
【請求項２０】
処理を開始する第１デバイスと、前記処理を遂行する手段と、前記処理を終了する第２デバイスとを含むデータ処理システムのシステムパフォーマンスをコンピュータに測定させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記処理の開始時に入力される入力データ、または、前記処理の開始により生成される開始通知データを受け取り、
ロギングデバイスのシステムクロックを用いて、前記入力データまたは前記開始通知データの受け取り時刻を含む処理開始時データを生成し、
前記ロギングデバイスが前記処理の終了により生成される終了通知データを受け取り、
前記ロギングデバイスのシステムクロックを用いて、前記終了通知データの受け取り時刻を含む処理終了時データを生成し、
前記処理開始時データおよび前記処理終了時データを比較して、前記処理に要した時間を算出する、機能を実現させるための記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ処理システム、データロギングシステム、システムパフォーマンスの測定方法および記録媒体に関し、特に、１つのタスクにおけるデータ処理を開始するデバイス（システム）とデータ処理を終了するデバイス（システム）が異なる場合のシステムパフォーマンスの測定に適用して有効な技術に関する。
【０００２】
【従来の技術】
通常、システム・インテグレーション・サービスやシステムのアウトソース・サービスを提供する場合、サービス提供者とクライアント（顧客）との間でサービス・レベルの同意がなされる。このため、その達成度合いを測定する必要がある。システムの応答時間に関するサービス・レベルを取り決める場合には、システムの開発、テストの段階から応答時間を計測、評価し、システムが本稼動した後においても応答時間を計測、評価し続ける必要がある。よって、客観的な応答時間の測定システム（システムパフォーマンスの測定技術）が必要になる。
【０００３】
ウェブ・アプリケーション・システムやクライアント・サーバ・システムの場合には、ユーザからのリクエストの発生場所と、ユーザへの応答の到達場所が一致している。このような場合には、リクエストを発生させ応答を受け取るシステムにおいて、リクエスト発生時から応答到達時までの時間をそのシステムのシステム・クロックによって計測することができる。
【０００４】
リクエストの発生場所と応答の到達場所が相違する場合には、たとえば標準時間を提供するサーバによる同期を利用して以下のように応答時間を測定できる。すなわち、リクエスト発生システムおよび応答到達システムの各々のシステムから標準時間提供サーバにアクセスし、各々のシステム・クロックを標準時に同期させる。そしてリクエストを発した時刻および応答を受け取った時刻を各々のシステムのシステム・クロックを用いてタイムスタンプを付加する。その後各時刻を一箇所に集めて応答時間を計算する。
【０００５】
【発明が解決しようとする課題】
リクエストの発生場所と応答の到達場所が相違する場合には、前記したリクエスト発生と応答場所が一致する場合の手法が適用できないことは勿論である。
【０００６】
また、前記した標準時（標準時提供サーバ）を用いてシステム・クロックの同期をとる手法においては、要求される時間精度が数秒程度の場合には特に問題を生じない。しかし、要求される時間精度がサブ秒（１秒以下）の場合には困難を伴う。インターネットにおいて、数１００ｍｓｅｃのオーダで同期をとる手法が確立されているものの、同期をとるためにはオーバーヘッドの情報が必要である。迅速な応答速度が要求されるシステムではこのオーバーヘッドが負荷として無視できなくなる。また、システム・クロックの常に正しい同期を実現することも容易ではない。特に、オリンピック競技等の大規模なシステムにおいては、応答速度の迅速性（１秒以下）が要求され、かつシステムを構成するデバイス（コンピュータシステム）の数も膨大になるため、各デバイスについて全て正しく同期をとることは困難である。
【０００７】
本発明の目的は、処理の開始場所（開始デバイス）と処理の終了場合（終了デバイス）が相違する場合に、たとえば１秒以下の高分解能な応答時間（処理時間）を計測する手法を提供することにある。
【０００８】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、処理の開始および終了の通知データを、その通知データ（メッセージ）を受け取った時刻のタイムスタンプとともに１つのロギングデバイスで記録する。メッセージに付されるタイムスタンプは、ロギングデバイスのシステム・クロックによる時刻である。これにより処理の開始時刻および終了時刻とする。そして計測された終了時刻と開始時刻との差分により処理時間を算出する。このように１つのロギングデバイス（システム・クロック）を用いて処理の開始および終了時刻を計測するため、システムクロックの同期を取る必要が無い。一方、ロギングデバイス内の唯一のシステム・クロックを用いるため、算出された処理時間は開始デバイスおよび終了デバイスのシステムクロックには依存しない。このため正確な処理時間を算出できる。
【０００９】
処理の開始および終了の通知データは、開始デバイスおよび終了デバイスで生成され、１つのロギングデバイスに送付される。処理の開始は開始デバイスへの入力データの入力を契機としてロギングデバイスが生成してもよい。
【００１０】
また、ロギングデバイスへの通知データの送付は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）またはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）を用いる。ＴＣＰまたはＵＤＰがＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）上で使用されるのは勿論である。１０Ｍｂｐｓの転送速度を有するイーサネットを用いれば、通知データは数ｍｓｅｃ程度のネットワーク遅延の範囲内でロギングデバイスに到達する。このため、数１００ｍｓｅｃ程度の測定精度には何ら影響を及ぼさない。なお、ＵＤＰの場合、そのプロトコルにおいてＡＣＫ（通信が確立しているかの確認機能）やＲＥＴＲＹ（データ再送信機能）処理をなくすことにより、より高い測定精度を実現できる。
【００１１】
また、処理開始の通知データと処理終了の通知データは、何らかの関連付けがなされている必要がある。一般的にデータ処理は開始デバイスへの入力データの入力で開始され、この入力データに所定のデータ処理が施されて終了デバイスで処理が終了する。このことから、終了データ（出力データ）には一般に入力データの内容が含まれる。よって、開始通知データに入力データを、終了通知データに出力データを含め、これらデータに含まれる一定のキーワードを用いて関連付けを行える。
【００１２】
あるいは、処理の開始または終了が各々の記憶装置への記録で特定できる場合には、各記録装置のファイルの変化を監視して通知データにそのファイル変化の内容を含めることができる。この場合、開始および終了の関連付けはファイル名（ディレクトリ名）およびファイルサイズによって行うことができる。また処理の開始または終了がＮＥＴＢＩＯＳ等のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）のメッセージで特定できる場合には、これらメッセージを監視して通知データにそのメッセージの内容を含めることができる。この場合、開始および終了の関連付けはメッセージに含まれるキーワードによって行うことができる。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００１４】
以下の実施の形態では、主に方法またはシステムについて説明するが、当業者であれば明らかなとおり、本発明は方法、システムの他、コンピュータで使用可能なプログラムが記録された媒体としても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムが記録された媒体としては、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置を含む任意のコンピュータ可読媒体を例示できる。
【００１５】
また以下の実施の形態では、各デバイスがコンピュータである場合、一般的なコンピュータシステムを用いることができる。実施の形態で用いるコンピュータシステムには、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）等を有し、バスで相互に接続される。バスには、その他コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等が接続されてもよい。バスには、適当なインターフェイスを介して外部記憶装置、データ入力デバイス、表示デバイス、通信制御装置等が接続される。その他、一般的にコンピュータシステムに備えられるハードウェア資源を備えることが可能なことは言うまでもない。外部記憶装置は代表的にはハードディスク装置が例示できるが、これに限られず、光磁気記憶装置、光記憶装置、フラッシュメモリ等半導体記憶装置も含まれる。データ入力デバイスには、キーボード等の入力装置、マウス等ポインティングデバイスを備えることができる。データ入力デバイスにはスキャナ等の画像読み取り装置、音声入力装置も含む。表示装置としては、ＣＲＴ、液晶表示装置、プラズマ表示装置が例示できる。また、コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。
【００１６】
図１は、本発明のデータ処理システムの一例を示した構成図である。本実施の形態では、オリンピック競技におけるタイミングデータの処理、ＴＶ画像処理、解説者用の情報システム処理の例を説明する。
【００１７】
本実施の形態のシステムには、イベントコントローラ（ＥＣ）１、データディスプレイシステム（ＤＤＳ）２、ＴＶインタフェイス（ＴＶ）３、ブロードキャスタインタフェイス（ＢｒＩｎｔ）４、スコアボードインタフェイス（ＳＢ）５、プリンタ（ＰＲ）６、イベントマネージャ（ＥＭ）７、コメンテータインフォメーションシステムインタフェイス（ＣＩＳＩＮＴ）８、インターネットリザルトフィードマシン（ＩＲＦ）９、データベースサーバ（ＤＢ）およびバックアップドメインコントロール（ＢＤＣ）１０、べニューコントロール（ＶＣ）およびプライマリドメインコントロール（ＰＤＣ）１１、ゲートウェイ（ＧＷ）１２、ロギングデバイス１３を含む。各機器はＬＡＮ１４およびルータ１５で接続される。
【００１８】
なお、本システムでは、ほぼ同様な構成のシステム１８をもう一つ有する。このようにシステム構成を二重化することにより、システムの一部が故障した場合にも迅速にバックアップシステムを稼動させて処理の遅れを生じさせないようにできる。オリンピック競技のように世界的に注目されている状況下での処理の遅延は許容できないため、システムの冗長性を高めたものである。
【００１９】
イベントコントローラ１はタイミングデバイス１６からのメッセージ（時刻データ）を受け取り、これを基に競技者の順位、競技者間の時間差等を計算する機能をもつ。計算結果はデータベース１０に書き込まれる。タイミングデバイスからのメッセージはスプリッタ１７により分割される。イベントコントローラ１は、競技の開始から終了すなわち競技者の全員がゴールするまでの処理を管理する。
【００２０】
データディスプレイシステム２はその先にＣＡＴＶが接続され、ＣＡＴＶの画面上にテキスト情報をフィードする機能をもつ。
【００２１】
ＴＶインタフェイス３は、ブロードキャスタインタフェイス４にたとえばＲＳ２３２Ｃを介してデータを送信する。ブロードキャスタインタフェイス４では、ＴＶ会社から供給されるＴＶ画像とデータが合成され、ブロードキャストとして全世界に映像が配信される。
【００２２】
スコアボードインタフェイス５は、たとえばＲＳ２３２Ｃを介して競技会場のスコアボードにデータを送信する機能をもつ。
【００２３】
プリンタ６は、データ（情報）をハードコピーとして印刷出力するための機器である。
【００２４】
イベントマネージャ７は、オペレータのデータ入力によってデータベース１０のデータを更新する機能をもつ。イベントマネージャ７は、競技が開始されるまで、及び競技が終了した後の処理を管理する。
【００２５】
コメンテータインフォメーションシステムインタフェイス８は、その先にコメンテータ情報システム（ＣＩＳ）のコントローラが接続され、さらにその先にＣＩＳワークステーションが接続される。コメンテータインフォメーションシステムインタフェイス８は最終的にはＣＩＳワークステーションに表示されるデータを転送する機能をもつ。競技場のアナウンサや解説者がＣＩＳワークステーションの表示を参照しながら実況中継等を行う。
【００２６】
インターネットリザルトフィードマシン９は、その先にＭＱサーバが接続され、最終的には公的に情報提供を行うインターネットサーバに接続される。インターネットリザルトフィードマシン９は、公開されるウェブサーバへのデータ転送の機能をもつ。
【００２７】
データベースサーバおよびバックアップドメインコントロール１０は、データベースサーバの機能とバックアップドメインコントロールの機能とを併せ持つ。データベースにはＥＣで計算された各種情報（順位、時間差、世界記録あるいはオリンピック記録であるか否か等の情報）を記録する。また、データベースにはＥＭから入力された情報が記録される。バックアップドメインコントロールは、バックアップシステム１８をコントロールする機能をもつ。
【００２８】
べニューコントロールおよびプライマリドメインコントロール１１は、本システムの全体を制御する。データベースサーバ１０のデータベースに記録されているデータ（情報）をＤＤＳ、ＴＶ、ＳＢ、ＰＲ、ＣＩＳＩＮＴ、ＩＲＦ、ＧＷ等に配布する。特に競技中のＥＣからのデータをＴＶ、ＣＩＳＩＮＴにリアルタイムで配布する重要な機能をもつ。
【００２９】
ゲートウェイ１２は、ＭＱサーバに接続され、リアルタイムでないデータをフィードする機能をもつ。データはオリンピック用イントラネットサービス（ＩＮＦＯ）サーバ、インターネットウェブサーバ、プリント配布サーバ、新聞社向けオリンピックニュース配信システム（ＷＮＰＡ）等に配布される。
【００３０】
ロギングデバイス１３は、本システムのパフォーマンス測定のためのデータをログするシステムであり、後に詳しく説明する。
【００３１】
なお、上記の各機器（１〜１２）は、これを複数有しても良く、また、各機器の機能を他のシステムに統合しても良い。たとえばパフォーマンス測定のためのシステムロギング機能をデータベースサーバ１０が有しても良い。但し、以下に説明するように本発明のシステムロギング機能では唯一のシステムクロックが参照される。このためシステムロギング機能については複数有することは許容されない。
【００３２】
図２は、本システムの一部を抜き出して示したブロック図であり、図３は本システムのパフォーマンス測定の流れの一例を示したフローチャートである。なお、本システムは前記の通り競技の開始前および競技の終了後はイベントマネージャ７で制御され、競技中はイベントコントローラ１で制御される。以下の説明ではより迅速な応答が要求される競技中の処理（イベントコントローラ１が動作している間）を中心に説明する。但し、本発明のパフォーマンス測定はイベントコントローラの制御下にある時にのみ有効なものではなく、その他本システムが稼動している間の任意の時期に適用可能なことは勿論である。
【００３３】
図２と図３を参照すれば、タイミングデバイス１６から供給されるタイミングデータ３０（Ｓ０１）は、スプリッタ１７でスプリットされ、一方がロギングデバイス１３に入力され（Ｓ０２）、他方はＥＣ１（イベントコントローラ）に入力される（Ｓ１１）。タイミングデータ３０はタイミング（時計）会社から供給されるものであり、その時計会社によって定められたフォーマットで供給される。タイミングデバイス１６とロギングデバイス１３あるいはＥＣ１との接続にはたとえばＲＳ２３２Ｃが用いられる。
【００３４】
ロギングデバイス１３に入力されたタイミングデータ３０はＳＴＳＩＭ３１で受け取る（Ｓ０２）。ＳＴＳＩＭ３１は、タイミングデータを受け取り、タイミングログファイル２１に逐次記録する機能をもつ（Ｓ０３）。タイミングログファイル２１に記録されたタイミングデータはシステムの故障等によりリプレイが必要な場合に読み出され、イベントコントローラ（ＥＣ）に供給される。
【００３５】
ＳＴＳＩＭ３１で受け取られた入力データはＤＩＳＴＲＩＢ３２に転送される。ＤＩＳＴＲＩＢ３２は、入力データを必要なデバイスに配布する機能をもつ。後に説明するように、本実施の形態のシステムログモニタ（ＬＡＮＬＡＮ３３）を含まない入力データログデバイス（スレーブＤＩＳＴＲＩＢ）にもＤＩＳＴＲＩＢが含まれる。このような入力データログデバイスにおいては、受け取った入力データをロギングデバイス１３のＤＩＳＴＲＩＢ３２に転送する機能をもつ。ここではシステムログモニタであるＬＡＮＬＡＮ３３を有するマスタデバイスについて説明している。よってＤＩＳＴＲＩＢ３２からＬＡＮＬＡＮ３３に入力データが配布される。
【００３６】
ＬＡＮＬＡＮ３３は、ＤＩＳＴＲＩＢ３２から受け取った入力データにタイムスタンプを付して（Ｓ０４）システムログファイル２０に記録する機能をもつ（Ｓ０５）。なお、タイムスタンプを付す機能はＤＩＳＴＲＩＢ３２によって実現しても良い。このタイムスタンプに用いられる時計はロギングデバイス１３のシステムクロックである。後に説明するようにＲＭＳｅｎｄｅｒから送付されたデータ（処理終了メッセージ）も同一のシステムクロックを用いてタイムスタンプが付される。このように同一のシステムクロックを用いるためパフォーマンスの測定を必要とする複数のシステム内のシステムクロックを同期させる必要がない。唯一のシステムクロックを用いることにより簡便に高精度のパフォーマンス測定が実現できる。ところで、このようにしてシステムログファイル２０に記録されたタイムスタンプ付きの入力データは、システムの処理開始時期を特定する機能をもつ。後に説明するようにタイムスタンプが付された終了メッセージとの差分により処理に要した時間が計算できる。なお、ＬＡＮＬＡＮ３３によってシステムログがビュア２２に表示される。
【００３７】
一方、イベントコントローラ（ＥＣ）１に入力されたタイミングデータ３０は、ＥＣ１で処理される（Ｓ１２）。ＥＣ１でのデータ処理は、たとえば競技者の順位の計算、時間差、世界記録あるいはオリンピック記録の参照である。これら計算により得られたデータ３４はべニューコントロール１１に送付され、ＣＩＳＩＮＴ８あるいはＴＶ３に転送される（３５，３６）。なお、ここではＣＩＳＩＮＴ８あるいはＴＶ３を例示しているが、その他のデバイス（ＤＤＳ、ＳＢ、ＰＲ、ＩＲＦ、ＧＷ）であっても以下の説明は同様である。但しその他のデバイスがＰＲの場合、ＰＲにはプリントサーバを含むものとする。あるいはＰＲはローカル接続されたプリンタを意味するものとする。
【００３８】
転送されたデータ３５、３６は、各々ＣＩＳＩＮＴ８内のＣＩＳＩｎｔ（ＣＩＳインタフェイス）コード３７、ＴＶＩｎｔ（ＴＶインタフェイス）コード４４により処理される（Ｓ１３）。この処理はたとえば各デバイスの先に接続されるシステムに適合した形式にデータをインタフェイスさせる処理である。この処理において各々初期設定ファイル（ＩＮＩファイル３８、４５）が参照される。そして、ＣＩＳＩｎｔコード３７によって処理されたデータ３９はＣＩＳコントロール４０に送付され（Ｓ１４）、コメンテータ情報システムにおいてこれが用いられる。ＴＶＩｎｔコード４４によって処理されたデータ４６はＢＲＩＮＴ４に送付され（Ｓ１４）、ＴＶ会社によってこれが用いられる。
【００３９】
データ３９、４６は、本実施の形態のシステム以外のシステムに送付されるデータであり、本実施の形態のシステムにとっては、タイミングデータ３０の入力から発生する一連の処理の終了を意味する結果データである。よって、本実施の形態のシステムのパフォーマンスを測定するのであれば、タイミングデータ３０が入力されてからデータ３９あるいはデータ４６が送出されるまでの時間を計測すればよい。タイミングデータ３０の入力時刻は前記の通りシステムログファイル２０に記録されている。よって、以下の通り処理の終了時刻（データ３９、４６の送出時刻）を計測する。
【００４０】
ＣＩＳＩｎｔコード３７はＣＩＳコントロール４０にデータ３９を送付するとともにＮＴパイプ４１を介してＲＭＳｅｎｄｅｒ４２にもデータ３９を送付する。また、ＴＶＩｎｔコード４４はＢＲＩＮＴ４にデータ４６を送付するとともにＮＴパイプ４８を介してＲＭＳｅｎｄｅｒ４９にもデータ４６を送付する。
【００４１】
ＲＭＳｅｎｄｅｒ４２，４９は、受け取ったデータ３９、４６（結果データ）を、ＴＣＰまたはＵＤＰ４３，５０を介してＤＩＳＴＲＩＢ３２に送付する。データ３９、４６を受け取ったＤＩＳＴＲＩＢ３２は、タイミングデータ３０の場合と同様にＬＡＮＬＡＮ３３に送付される。データ３９，４６にはタイムスタンプが付加され（Ｓ０４）、システムログファイル２０に記録される。
【００４２】
タイムスタンプが付されたデータ３９あるいはデータ４６は、一連の処理の終了時刻を特定する機能をもつ。正確には処理の終了はデータ３９，４６がＣＩＳコントロール４０あるいはＢＲＩＮＴ４等に送出された時刻であるため、ＤＩＳＴＲＩＢ３２がデータ３９，４６を受け取った時刻とは相違する。しかし、本実施の形態ではＲＭＳｅｎｄｅｒ４２，４９とＤＩＳＴＲＩＢ３２との間はＴＣＰまたはＵＤＰ４３，５０で接続され、データ転送速度が１０Ｍｂｐｓの比較的遅い仕様のイーサネットを用いても転送遅延は数ｍｓｅｃのオーダに過ぎない。本実施の形態におけるパフォーマンス測定の要求精度は１００ｍｓｅｃのオーダなので、ＲＭＳｅｎｄｅｒ４２，４９からＤＩＳＴＲＩＢ３２へのデータ転送遅延はほとんど問題にならない。
【００４３】
データ３９，４６に付されるタイムスタンプにはロギングデバイス１３内のシステムクロックすなわちタイミングデータ３０のタイムスタンプに用いられたと同じシステムクロックが用いられる。処理の開始と終了を同一の時計を用いて計測するため、システムクロックの同期を取る必要がない。また、簡便に精度の高い処理時間の計測が実現できる。なお、タイムスタンプつきのデータ３９あるいは４６（処理終了時データ）とタイムスタンプ付きのタイミングデータ（処理開始時データ）との差を計算し処理時間を算出する処理は後に説明する。
【００４４】
このようにして、処理の開始時を特定するデータと処理の終了時を特定するデータとがシステムログファイル２０に逐次記録される。
【００４５】
上記では、タイミングデバイス１６が１つの場合を例示しているが、タイミングデバイス１６は複数在っても良い。複数のタイミングデバイスが並列にスプリッタ１７に接続され、複数のタイミングデバイスから１つのスプリッタ１７にタイミングデータが入力されても良い。但し１つのスプリッタに複数のタイミングデバイスからのタイミングデータが入力される場合には、スプリッタ１７にはタイミングデータの終端検出機能等のインテリジェンスな機能が備えられている必要がある。
【００４６】
また、図４に示すように、複数のタイミングデバイス１６，１６ｂが各々スプリッタ１７を介してロギングデバイス１３および他の入力データログシステム５１に接続されても良い。入力データログシステム５１は前記ＳＴＳＩＭ３１およびＤＩＳＴＲＩＢ３２と同様な機能をもつＳＴＳＩＭ５２およびＤＩＳＴＲＩＢ５３を有する。タイミングデバイス１６ｂからスプリッタ１７を介してＳＴＳＩＭ５２に入力（Ｓ０８）されたタイミングデータ３０ｂ（Ｓ０７）は、ロギングデバイス１３の場合と同様にタイミングログファイル２１に逐次記録される（Ｓ１０）。そして、タイミングデータ３０ｂはＳＴＳＩＭ５２からＤＩＳＴＲＩＢ５３に転送され、ＤＩＳＴＲＩＢ５３は、タイミングデータ３０ｂをロギングデバイス１３のＤＩＳＴＲＩＢ３２に配布する（Ｓ０９）。ＤＩＳＴＲＩＢ３２で受け取られたタイミングデータ３０ｂの処理は前記同様である。
【００４７】
ここで、ＤＩＳＴＲＩＢ５３からのタイミングデータ３０ｂの送信はＴＣＰまたはＵＤＰ５４を介して行われる。ＴＣＰまたはＵＤＰ５４は少なくとも１０Ｍｂｐｓ程度の転送速度を有し、ネットワーク遅延は前記の通り数ｍｓｅｃのオーダである。タイミングデータ３０ｂの入力により開始される処理の始点は本来ＳＴＳＩＭ５２にデータが入力された時点であるが、ネットワーク遅延が無視できることから、ＤＩＳＴＲＩＢ３２またはＬＡＮＬＡＮ３３においてロギングデバイス１３内のシステムクロックによりタイムスタンプが付される時点を処理の始点として取り扱うことができる。すなわち、タイミングデータがロギングデバイス１３のＳＴＳＩＭ３１に直接入力される場合であっても、また、他の入力ログシステム５１を介して入力される場合であっても、ＤＩＳＴＲＩＢ間が転送速度の速いネットワークたとえばＴＣＰまたはＵＤＰでＩＰ接続される場合には処理開始時間の特定においてロギングデバイス１３内の１つのシステムクロックを用いてタイムスタンプを付す手段を採用することができる。なお、図４の説明において図２と重複する部分の説明は省略した。
【００４８】
図５は、システムログファイル２０に記録されるデータの一例を示した図である。１行が１つのデータセットに対応する。各データにおいて記号「Ｆ」に続く小数点以下３桁の固定小数点表示された数字、たとえば１行目の「１３９４４．７８３」がタイムスタンプである。単位は秒であり、ロギングデバイス１３のシステムクロックがカウントを開始し始めてからの時間を表す。各データに含まれる「ＳＴＳＩＭ」「ＴＶＩＮＴ」「ＣＩＳＩＦ」の文字は、そのデータの発送元デバイスを示す。よって、「ＳＴＳＩＭ」の文字を含むデータは何らかの処理の開始時刻を特定し、「ＴＶＩＮＴ」「ＣＩＳＩＦ」の文字を含むデータは何らかの処理の終了時刻を特定する。
【００４９】
システムログファイル２０に記録された各データ間の関連付け、つまり一連の処理の開始と終了を示す各々のデータの抽出はたとえば以下のように行える。図６はシステムログファイル２０内に記録されたデータ間の関連付けを説明するための図である。
【００５０】
図６において上段のデータはＳＴＳＩＭで受け取られたデータであり処理の開始時点を特定するデータであることがわかる。ここで例示したデータは水泳競技におけるタイミングデータであり、矢印６０で示した部分に競技者のレーン番号（図６上段においては第４レーン）が含まれている。また当該レーンの競技者の中間タイムが矢印６１に示した部分に含まれる（図６上段においては３０．００秒）。これら競技者ごとに相違するであろうデータに着目して、処理の終了時刻を特定するデータのうち、当該開始時刻データに対応する終了時刻データを検索する。
【００５１】
図６中段に示したデータは「ＴＶＩＮＴ」の文字を含むためＴＶＩＮＴ４４までの一連の処理の終了時刻を特定するデータであることがわかる。また、中段のデータには、競技者のレーン番号を示すデータ（矢印６２の部分）及び中間タイムを示すデータ（矢印６３の部分）を含む。これら各データの内容を参照すれば、各々「４」「３０．００」であり、上段のＳＴＳＩＭからのデータに対応することが判断できる。よって、図５に示すような各データの中から上段に示すデータとの関連付けが行える。上段のデータが入力されることにより発生したＴＶ画像生成の処理（ＢＲＩＮＴ４に適合する必要なデータの生成処理）には「１３９７２．８９６」−「１３９７２．８０２」＝０．０９４秒の時間を要したことが判る。なお、この処理時間（応答時間）の計算は後に説明する計算システム７１によって行われる。
【００５２】
同様に図６下段に示した「ＣＩＳＩＦ」からのデータとの関連付けも行える。下段データにおいて矢印６４の部分にレーン番号を示すデータが含まれ、矢印６５の部分に中間タイムを示すデータが含まれる。中段データと同様に各々「０４」「３０．００」の内容を含み、上段データと関連付けられることが判る。よって、上段データと下段データとから、ＣＩＳ（コメンテータ情報システム）コントローラに送出するに必要なデータの生成に「１３９７３．３６６」−「１３９７２．８０２」＝０．５６４秒の時間を要したことが判る。
【００５３】
図７は算出される処理時間を示した図である。時刻ｔ０でタイミングデバイス１６からのタイミングデータが入力される。図６においては上段のデータで時刻が特定できる。その後、イベントコントローラ（ＥＣ）での処理が行われ、続いてＣＩＳインタフェイス（ＣＩＳＩｎｔ）への処理が行われ、並行してＴＶインタフェイス（ＴＶＩｎｔ）への処理が行われる。ＴＶＩｎｔでの処理が終了した時点（ｔ１）でＢＲＩＮＴにデータが出力され、同時にＲＭＳｅｎｄｅｒを介して出力データがロギングデバイス１３に送付される。図６においては中段のデータでｔ１が特定できる。ＣＩＳＩｎｔでの処理が終了した時点（ｔ２）でＣＩＳコントローラにデータが出力され、同時にＲＭＳｅｎｄｅｒを介して出力データがロギングデバイス１３に送付される。図６においては下段のデータでｔ２が特定できる。これらｔ０〜ｔ２のデータを用いて処理発生からＣＩＳＩｎｔ処理の終了までの時間Ｔｃｉｓおよび処理発生からＴＶＩｎｔ処理の終了までの時間Ｔｔｖを算出する。ＴｃｉｓおよびＴｔｖが各々の処理に係るシステムのパフォーマンスを示すこととなる。
【００５４】
図８はシステムパフォーマンスのレポート処理を行うシステムの一例を示す図である。各種競技のローカルリザルトを前記したようにロギングデバイス１３を用いてシステムログファイル２０に記録する。たとえば１日の競技が終了した時にシステムログファイル２０の内容をログファイル７２に転送し、処理速度（応答速度）を前記した方法で計算する。ログファイル内の各データの関連付けおよび処理時間の計算は計算システム７１により自動的に行える。なお、各競技ごとにデータのフォーマットが相違し、関連付けに必要なデータも異なるので、各種競技のログファイルをセンタ７０（ＴＣＣ：テクノロジコマンドセンタ）に集約して統一的にデータを取り扱う意義がある。
【００５５】
計算が終了したデータはリデュースプログラム７３を用いてリデュースファイル７４に変換し、パフォーマンスレポータ７５にアップロードする。パフォーマンスレポータ７５では、各競技ごとに異なっていたフォーマットを変換して所定のフォーマットに統一し、システムのパフォーマンスをたとえば競技ごと、マシンごとに見やすい形態で表示出力する。パフォーマンスレポートはデータベース７６に蓄積され、随時参照できるようにする。なお、処理応答時間の計算は、必ずしもセンタ７０で行う必要は無く、ローカルリザルトシステム内で行っても良いことは勿論である。
【００５６】
本実施の形態のシステムによれば、処理の開始場所と終了場所とが相違する場合であっても簡便かつ精度良く処理にかかる時間を計測できる。これにより、たとえばオリンピックの競技結果を表示加工するような大規模かつ複雑なシステムにおけるシステムパフォーマンスの測定を容易にできる。
【００５７】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【００５８】
たとえば、前記実施の形態では、ＣＩＳインタフェイスおよびＴＶインタフェイスを例に挙げて説明したが、その他のデバイス（ＤＤＳ、ＳＢ、ＩＲＦ等）についても同様にＲＭＳｅｎｄｅｒを備えて本実施の形態と同様にそのデバイスにかかる処理時間を計測できる。
【００５９】
また、前記実施の形態では、処理開始の契機としてタイミングデータの入力の場合を説明したが、これに限られず、他の任意のデータが入力されてもよいことは勿論である。
【００６０】
また、処理開始、処理終了の各契機は、システム外部からのデータの入力あるいはシステムからのデータの出力に限られず、ＲＳ２３２Ｃのシリアルアウトプット、ハードディスク装置（ＨＤＤ）に書き込まれるログ情報、各種ファイルのアウトプット情報、ＮＥＴＢＩＯＳ等のネットワークメッセージのアウトプット等や、モニタプログラムでモニタできるあらゆるシステムイベントが処理の開始および終了時刻を検出するデータになりえる。
【００６１】
たとえば、図９に示すようなシステムにおいては、ローカルリザルトシステム内のＥＣ１がタイミングデバイス１６からのデータを受信後、ＶＣ１１のフレーム（ＨＤＤ）８１に計算結果を書き込むまでの時間を計測できる。ＨＤＤへの書き込みイベントをリアルタイムに検出する方法は、たとえばＯＳにＡＰＩとして供給されているファイル変更時のイベント通知を用いる手法、あるいは一定期間（たとえば５００ｍｓｅｃ）ごとにＨＤＤのディレクトリ情報をスキャンする手法がある。これら手法によりファイル変更等のイベントを検出した時には、変更内容（日付、サイズ、ファイル名等）のパケットを生成し、これを本発明のロギングデバイス１３にＵＤＰ等を介して送付できる。ログデータの関連付けはファイル名、サイズ等を用いることができる。
【００６２】
また、図９に示すシステムにおいては、ＣＩＳインタフェイス８からＭＱ、ＣＩＳコントローラ４０を経由してデータがＣＩＳワークステーション８２に到達するまでの時間を計測できる。ＣＩＳコントローラ４０とＣＩＳワークステーション８２との間はＮＥＴＢＩＯＳにより接続されているためＮＥＴＢＩＯＳのメッセージが捕捉できる。このメッセージをパケットに加工してＵＤＰ等を介しロギングデバイス１３に送付することにより実施の形態と同様な時刻特定が可能になる。ログデータ間の関連付けはメッセージ内容を用いることで可能となる。
【００６３】
また、前記と同様にＮＥＴＢＩＯＳのメッセージを用いてＣＩＳインタフェイス８からＣＩＳワークステーション８２（ローカルワークステーション）への到達時間とＣＩＳインタフェイス８からＣＩＳワークステーション８７（リモートワークステーション）への到達時間の差を計測し、セントラルシステムを経由した場合の遅延時間を知ることができる。この場合全く同一のメッセージが異なる経路でログされるため、ログデータ間の関連付けは容易に行える。
【００６４】
また、図１０に示すシステムにおいては、ローカルリザルトシステムのイベントマネージャ（ＥＭ）７で作成されたファイルがＷＮＰＡ（新聞社向けオリンピックニュース配信システム）のデータベース９１に記録された時点から、そのファイルがＭＱＳｅｎｄｅｒ９２、ＭＱ、セントラルシステムのＷＮＰＡディストリビュータ９５を介してＷＮＰＡサーバのＨＤＤ９７に記録されるまでの時間、あるいはさらにＲＳ２３２Ｃを介してＷＮＰＡ端末９８のＨＤＤに記録されるまでの時間を計測できる。イベント（ＨＤＤへの記録）検出の方法およびログデータ間の関連付けは前記の通りである。
【００６５】
あるいは、ＥＭ７で作成されたプリントファイルがセントラルシステムのプリントディストリビュータ９３を介してプリントサーバ９４のＨＤＤに蓄積されるまでの時間を計測できる。この場合、ログファイルの関連付けはファイル名およびサイズ情報にヘッダ情報分のサイズ増加分を加算して関連付けることができる。
【００６６】
また、前記実施の形態ではオリンピック競技の結果情報の表示、加工、編集、制御等を行うシステムに本発明を適用した例を説明した。大規模かつ複雑なシステムであるほど本発明の効果は顕著であるが、本発明はシステムの規模、複雑さ、目的には制限されない。すなわち、処理の開始場所および終了場所の異なるシステムにおいて処理時間を計測しようとするあらゆる用途、あらゆるシステムに本発明は適用可能である。
【００６７】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、処理の開始場所（開始デバイス）と処理の終了場合（終了デバイス）が相違するシステムにおいて、たとえば１秒以下の高分解能な応答時間（処理時間）を容易に計測することができる。しかもシステムが大規模かつ複雑であっても、計測の精度および簡便さが損なわれることはない。
【図面の簡単な説明】
【図１】本発明のデータ処理システムの一例を示した構成図である。
【図２】本システムの一部を抜き出して示したブロック図である。
【図３】本システムのパフォーマンス測定の流れの一例を示したフローチャートである。
【図４】本システムの一部を抜き出して示した他の例を示すブロック図である。
【図５】システムログファイルに記録されるデータの一例を示した図である。
【図６】システムログファイル内に記録されたデータ間の関連付けを説明するための図である。
【図７】算出される処理時間を示した図である。
【図８】システムパフォーマンスのレポート処理を行うシステムの一例を示す図である。
【図９】本発明のデータ処理システムの他の例を示した構成図である。
【図１０】本発明のデータ処理システムのさらに他の例を示した構成図である。
【符号の説明】
１…イベントコントローラ（ＥＣ）、２…データディスプレイシステム（ＤＤＳ）、３…ＴＶインタフェイス（ＴＶ）、４…ブロードキャスタインタフェイス（ＢｒＩｎｔ）、５…スコアボードインタフェイス（ＳＢ）、６…プリンタ（ＰＲ）、７…イベントマネージャ（ＥＭ）、８…コメンテータインフォメーションシステムインタフェイス（ＣＩＳＩＮＴ、ＣＩＳインタフェイス）、９…インターネットリザルトフィードマシン（ＩＲＦ）、１０…データベースサーバ（データベース），バックアップドメインコントロール（ＢＤＣ）、１１…ベニューコントロール，プライマリドメインコントロール（ＰＤＣ）、１２…ゲートウェイ（ＧＷ）、１３…ロギングデバイス、１４…ＬＡＮ、１５…ルータ、１６，１６ｂ…タイミングデバイス、１７…スプリッタ、１８…バックアップシステム、２０…システムログファイル、２１…タイミングログファイル、２２…ビュア、３０，３０ｂ…タイミングデータ、３３…ＬＡＮＬＡＮ、３４，３５…データ、３７…ＣＩＳＩｎｔコード、３８…ＩＮＩファイル、３９，４６…出力データ、４０…ＣＩＳコントローラ、４１，４８…ＮＴパイプ、４４…ＴＶＩｎｔコード、５１…入力データログシステム、７０…センタ、７１…計算システム、７２…ログファイル、７３…リデュースプログラム、７４…リデュースファイル、７５…パフォーマンスレポータ、７６…データベース、８１…フレーム（ＨＤＤ）、８２…ＣＩＳワークステーション、８７…ＣＩＳワークステーション、９１…データベース、９３…プリントディストリビュータ、９４…プリントサーバ、９５…ＷＮＰＡディストリビュータ、９８…ＷＮＰＡ端末。
【図１】
0003579826.tif 000002
【図２】
0003579826.tif 000003
【図３】
0003579826.tif 000004
【図４】
0003579826.tif 000005
【図５】
0003579826.tif 000006
【図６】
0003579826.tif 000007
【図７】
0003579826.tif 000008
【図８】
0003579826.tif 000009
【図９】
0003579826.tif 000010
【図１０】
0003579826.tif 000011