0

我有一个组件，它执行以下操作

  1. 使用基于源 A 的 tcp/ip 构建的自定义协议通过网络接受 SINGLE 消息
  2. 处理消息（大约需要 500 微秒）
  3. 使用基于 tcp/ip 构建的自定义协议通过网络将消息发送到不同的组件，例如端点 B
  4. 从端点 B 接收 ACK
  5. 向源 A 发送 ACK

冲洗并重复上述 5 个步骤。重要的是要了解源 A 不会发送第二条消息，直到它收到前一条消息的 ACK。

如您所见，该进程在以下情况下处于空闲状态

  1. 源 A 通过网络向组件发送一条消息的时间。源 A 和组件都在同一个 VLAN、以太网中。

  2. 组件将处理后的消息发送到端点 B 的时间。端点 B 也在通过以太网连接的同一 VLAN 中。

  3. 组件从端点 B 接收 ACK 的时间。

  4. 组件向源 A 发送 ACK 的时间。

以上是对组件职责的描述。从部署的角度来看，我计划在一台 8 核机器上生成 100 个这些组件。没有其他东西可以在机器上运行。端点 B 和源 A 都在不同的机器上，并且一切都在同一个以太网中。我的问题是，上述生成大量组件的模型是否会花费大部分时间等待网络 IO 导致上下文颠簸？如果是，为什么？

4

1 回答 1

0

I am not sure why you are worried. First you design an inefficient protocol then worry about how fast it will be?

Measure it, it is the only way to be sure.

I doubt that a mere 100 threads or processes will cause any problems with context switch rate.

于 2012-01-06T19:49:51.740 回答