テスト プログラムでの複数のプロトコルの使用

CCITCP プロトコルと CCISMEM プロトコル間の切り替えは、テスト プログラムのタイミングに影響を与える可能性があります。

通常、ドライバー レベルへのアクセスの場合、コンテキストは送信試行の開始後すぐに送信処理から切り替えます。特にピア処理では、コンテキストが元の処理に戻る前に CPU を使用します。

このため、CCITCP を使用すると、ドライバー レベルで必要な処理時間が、呼び出すドライバー アプリケーションがない CCISMEM を使用した場合よりも長くなります。CCITCP がドライバーに移動して追加のデータ移動を実行すると、コンテキストは親プロセスから切り替えられます。その一方、同じ送信操作で CCISMEM を使用した場合、コンテキストの切り替えは発生しません。CCI 呼び出し元では、そのピアに切り替える時期を管理します。

構成を非同期モード (デフォルト) に設定すると、File Share は読み取るデータが存在するかどうかを判断するために CCI をポーリングします。そのため、ユーザー レベルで CPU 処理にかなりの時間を費やして、処理する次のバッファを待機することになります。アプリケーションおよび File Share では、完全なタイムスライスが終了するまでコンテキストを対話ピアに切り替えません。つまり、CPU は、完全なタイムスライスが終了するまで、データの次のチャンクを処理して元の送信側に応答できません。

多くの場合、これは、スクロール画面表示があるポーリング ループで作成したテスト アプリケーションを使用するときに、高負荷のシングル CPU システムやデュアル/クワッド コア システムに極めて大きな影響を及ぼす可能性があります。

ウィンドウのハイライトおよび選択解除を行うと、これによってクライアントおよびサーバーのシステムの優先順位が変更になり、これによって、パートナー プロセスが作業を行う妨げにならないようポーリングを行うのに費やされる時間が変更されるため、クライアントおよびサーバーで費やされる時間が変わります。

このような場合、最短ルートは常に、クライアントまたはサーバーをハイライトしないことです。その結果、クライアントとサーバーは最短のタイムスライスで同じ CPU 使用率を取得します。これは、CPU の使用率が低すぎるのではなく高すぎる状態で実行しているプロセスの例です。

当然ながら、最速の設計はまったくループしないことです。ループせずに、インバウンド データが到着したときに適切な場所で受信し、さらに冗長ポーリングで CPU サイクルを無駄にせずにすばやく応答すれば速くなります。

ポーリング ループを回避するように、File Share を構成できます。