0

次のことを行うコンポーネントがあります

  1. ソース A からの tcp/ip を介して構築されたカスタム プロトコルを使用して、ネットワーク経由で単一のメッセージを受け入れる
  2. メッセージを処理します (約 500 マイクロ秒かかります)
  3. tcp/ip で構築されたカスタム プロトコルを使用して、ネットワーク経由で別のコンポーネント (エンドポイント B など) にメッセージを送信します。
  4. エンドポイント B から ACK を受信
  5. ソース A に ACK を送信

すすぎ、上記の 5 つの手順を繰り返します。ソース A は、前のメッセージに対する ACK を受信するまで、2 番目のメッセージを送信しないことを理解することが重要です。

ご覧のとおり、次の場合、プロセスはアイドル状態です

  1. ソース A がネットワーク経由で 1 つのメッセージをコンポーネントに送信する時間。ソース A とコンポーネントの両方が同じ VLAN、イーサネット内にあります。

  2. コンポーネントが処理されたメッセージをエンドポイント B に送信する時間。エンドポイント B も、イーサネット経由で接続された同じ VLAN 内にあります。

  3. コンポーネントがエンドポイント B から ACK を受信する時間。

  4. コンポーネントがソース A に ACK を送信する時間。

上記は、コンポーネントの責任の説明でした。展開の観点から、単一の 8 コア マシンでこれらのコンポーネントを 100 個生成することを計画しています。マシン上で実行されるものは他にありません。エンドポイント B とソース A は両方とも異なるマシン上にあり、すべてが同じイーサネット内にあります。私の質問は、ネットワーク IO の待機にほとんどの時間を費やす多数のコンポーネントを生成する上記のモデルは、コンテキストのスラッシングを引き起こすのでしょうか? はいの場合、なぜですか？

4

1 に答える 1

0

なぜ心配しているのかわかりません。最初に非効率的なプロトコルを設計し、次にそれがどれだけ速くなるかを心配しますか？

それを測定してください、それは確実にする唯一の方法です。

たった100個のスレッドまたはプロセスがコンテキストスイッチレートに問題を引き起こすとは思えません。

于 2012-01-06T19:49:51.740 に答える