我们最近完成了对组播发送性能的分析。令人高兴的是，Java和C几乎完全相同，因为我们在Windows和Solaris上测试了不同的流量发送速率。
但是，我们注意到发送多播消息的时间随着发送之间的时间的增加而增加。我们调用send越频繁，完成发送调用所需的时间就越少。
应用程序让我们控制在调用send之间等待的时间，在下面你会看到随着数据包之间的延迟增加而增加的时间。当发送1000个包/秒（1毫秒等待时间）时，调用发送只需要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/
答案 0 :(得分：3)
这可能是中断与该特定主机上的NIC合并的工件，请查看29 West关于该主题的文章，它们显示e1000网卡上的延迟可以增加到125μs，
http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html
答案 1 :(得分：2)
一些理论：
我的第一个想法是，我会考虑将缓存作为一个因素 - 如果任务和值仍然在堆栈或最近的短期内存中，您可能会发现它能够更快地发送它们。随着时间的推移，它仍然存在的可能性会降低，因此平均需要更长的时间。
但是，如果是这种情况，我希望会有一个上限...某些点总是在缓存中。
另一个原因是您的app / test / platform中存在内存泄漏或性能下降的情况。这也（如果存在）意味着等待的时间越长，降低性能的时间就越长，因此发送的时间就越长。
另外 - 如果您在数据包之间花费更长时间来发送它们 - 您可能会超出地址学习超时 - IP表和MAC表。如果这些表/缓存已过期，则需要在转发数据包之前重新学习它们。
祝你好运！答案 2 :(得分：1)
当刚刚发生呼叫时，执行这些任务的代码会缓存到CPU附近（甚至可能仍然在寄存器中）。
答案 3 :(得分：1)
你们如何在发送之间等待？您是否尝试过忙等待，以免放弃CPU？