5

我们最近完成了对多播发送性能的分析。令人高兴的是，当我们在 Windows 和 Solaris 上测试不同的流量发送速率时，Java 和 C 的性能几乎相同。

但是，我们注意到发送多播消息的时间随着发送之间时间的增加而增加。我们调用发送的频率越高，完成发送调用所需的时间就越少。

该应用程序允许我们控制在调用发送之间等待的时间量，在下面您会看到随着数据包之间的延迟增加而增加的时间。当发送 1000 个数据包/秒（1 ms 等待时间）时，调用 send 只需要 13 微秒。在 1 个数据包/秒（1000 毫秒等待时间）下，该时间增加到 20 微秒。

Wait time (ms)                      us to send
0                                   8.67   
1                                   12.97  
10                                  13.06  
100                                 18.03  
1000                                20.82
10000                               57.20

我们在 Java 和 C 以及 Windows 和 Solaris 上都看到了这种现象。我们正在使用 Intel Pro 1000 双端口网卡的戴尔 1950 服务器上进行测试。微基准测试很难，尤其是在 Java 中，但我们认为这与 JITing 或 GC 无关。

我用于测试的 Java 代码和命令行位于：http ://www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

4

4 回答 4

3

这可能是与特定主机上的 NIC 的中断合并的产物，请查看 29 West 关于该主题的这篇文章，他们展示了 e1000 NIC 上的延迟如何增加到 125μs，

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

于 2010-02-06T05:06:44.137 回答
2

一些理论：

我的第一个想法是我会考虑将缓存作为一个因素 - 如果任务和值仍在堆栈上或最近的短期内存中，您可能会发现它能够更快地发送它们。随着时间的增加，它仍然可用的机会减少，因此平均需要更长的时间。

但是，如果是这种情况，我希望会有一个上限......它总是在缓存中。

另一种推理是，随着时间的推移，您的应用程序/测试/平台中存在内存泄漏或性能下降。这也将（如果存在）意味着您等待的时间越长，降低性能的时间就越长，因此发送所需的时间就越长。

另外 - 如果您在数据包之间花费更长的时间来发送它们 - 您可能会超过地址学习超时 - IP 表和 MAC 表。如果这些表/缓存已经过期，他们需要在转发数据包之前重新学习它们。

祝你好运！

于 2009-09-18T14:37:02.930 回答
1

当调用刚刚发生时，执行这些任务的代码被缓存在更靠近 CPU 的地方（甚至可能仍在寄存器中）。

于 2009-09-18T14:40:23.363 回答
1

您在发送之间如何等待？您是否尝试过忙于等待以免放弃 CPU？

于 2010-02-06T09:22:15.733 回答