Windows是否可以每秒处理数百万个数据报？

我正在研究是否可以在Windows上实现一个HPC应用程序，该应用程序可以使用十几个或多达200个多播组（即使用MSI-X和RSS ）以高速率接收较小的UDP多播数据报（大多数为100-400字节）。扩展到多个内核），对每个数据包进行一些处理，然后将其发送出去。通过TCP发送时，我设法达到了我所需要的最大速度（6.4Gb / sec），而没有遇到障碍，但是以高pps速率接收数据报却成为一个问题。

在Windows 2012 R2上使用2端口10Gb以太网NIC的高规格NUMA计算机上的最新测试中，我每秒只能接收数十万个UDP数据报（早期丢弃，即没有实际处理数据）。使用2x12内核从等式中删除我的应用程序的处理开销，以了解它的运行速度），并且测试的12个多播组的内核部分似乎分布在一个NUMA节点的8或10个内核中（设置了最大RSS队列）到16）-尽管使用了.net应用，所以本地应用应该能够运行得更快。

但即使莱恩霍尔盖特 只设法在500kpps接收UDP数据包在他的高性能的Windows RIO测试，使用1024个字节的UDP有效载荷。

在QLogic的白皮书（未提及被测操作系统）中，“多线程超小数据包路由”（包括接收和后续发送？）的限制设置为5.7Mpps。在有关Linux网络的文章中，限制设置为每个内核1Mpps到2Mpps（据报道线性地或多或少地线性扩展），或者使用绕过内核的特殊解决方案甚至设置为15Mpps。

例如网图

只需一个运行在900Mhz的内核，就可以在10GigE链路上以线速（14.88Mpps）生成流量。这相当于每个数据包大约60-65个时钟周期，并且可以随内核和时钟频率很好地扩展（对于4个内核，在不到450 MHz的频率下实现了线速）。在接收端达到相似的速率。

那么，我可以带（最新版本的）Windows / Windows Server走多远，尤其是如前所述，接收UDP多播呢？

编辑有一个cloudflare博客文章-一个有趣的评论部分-有关如何在Linux上做到这一点：如何每秒接收一百万个数据包，并且有相应的黑客新闻评论页面。

根据Microsoft的说法，他们实验室中的测试表明RIO可以“在早期测试的特定服务器上” 进行处理

• 在Windows Server 2008R2中2Mpps不会丢失，即没有RIO
• 使用RIO在（预发行）Windows Server 8上达到4Mpps

该视频的屏幕截图（44:33）：

因此，我的问题的答案Is it possible to process millions of datagrams per second with Windows?是：是的，并且显然甚至在Windows Server 2008R2中的RIO之前。

但是，除了官方数据（尤其是未发布的软件）外，还必须花一点点盐，仅在此演示文稿中提供稀疏信息，还存在许多关于测试的问题，以及如何正确解释结果的问题。最相关的是：

1. 是发送数字吗？接收？或者也许用于路由（即接收+发送）？
2. 什么数据包大小？->可能是最低的，这通常是在尝试让pps数字吹牛时做的
3. 多少个连接（如果是TCP）/数据包流（如果是UDP）？->尽可能多地分配工作负载，以便可以使用现有的所有内核
4. 什么测试设置？机器和NIC规格和接线

第一个至关重要，因为“发送”和“接收”需要不同的步骤，并且在性能上可能表现出很大的差异。对于其他数字，我们可能假设在高规格机器上使用了最小的数据包大小（每个内核至少有一个连接/数据包流）来获得最大的Mpps数据。

编辑我偶然发现了有关Linux 上高性能数据包处理的英特尔文档，据此，（Linux）

平台可以维持每秒约200万笔交易的交易速率

使用标准Linux网络堆栈（在具有2x8内核的物理主机上）。此请求/回复测试中的交易包括

1. 接收UDP数据包
2. 随后转发该数据包

（使用netperf的netserver）。该测试并行运行100个事务。对于感兴趣的人，本文中还有更多详细信息。我希望我们有类似这样的东西供Windows进行比较...无论如何，这是该请求/回复测试最相关的图表：

tl; dr

为了给出明确的答案，似乎需要更多测试。但是，间接证据表明，Linux是实际上仅在超低延迟社区中使用的操作系统，该社区还定期处理Mpps工作负载。这并不意味着Windows不可能，但是Windows可能会落后很多，即使有可能达到Mpps数值。但这需要确定测试，例如找出可以达到多少（CPU）成本。

注意：这不是我要接受的答案。它旨在为对这个问题感兴趣的任何人提供一些有关我们的立场以及在哪里进行进一步调查的提示。

谷歌认为，伦·霍尔盖特（Len Holgate）似乎是唯一测试RIO来提高Windows网络性能（并发布结果）的人，他在博客中发表评论澄清说他正在使用单个IP /端口组合用于发送UDP数据包。

换句话说，他的结果应该可以与Linux上的测试中的单核数字相媲美（尽管他使用的是8个线程-在未检查其代码的情况下，当仅处理一个UDP数据包流而不是处理单个UDP数据包流时，似乎对性能有害。对数据包进行任何繁重的处理，他提到实际上只使用了很少的线程，这很有意义）。尽管他说：

我并不是为了比较新旧API之间的相对性能而竭尽全力，所以我在测试中没有那么详尽。

但是，除了“努力”之外，对于更粗糙的RIO世界，又是什么放弃了标准IOCP的（相对）舒适区？至少就单个UDP数据包流而言。

我想他的意思是-他没有在RIO的多个测试中尝试各种设计方法时-就是说，他没有例如微调NIC设置来挤出最后的性能。例如，在接收缓冲区大小的情况下，这可能会对UDP接收性能和丢包率产生巨大的积极影响。

但是，当尝试直接将其结果与其他Linux / Unix / BSD测试的结果进行比较时，问题在于：大多数测试在尝试突破“每秒数据包”边界时，都使用最小的数据包/帧大小，即以太网64字节的帧。Len测试了1024个字节的数据包（-> 1070字节的帧），（特别是对于No-Nagle UDP）可以为您提供更高的“每秒位数”数字，但对于较小的数据包可能无法达到pps极限。因此，按原样比较这些数字将是不公平的。

到目前为止，总结我对Windows UDP的搜索结果可得到的性能：

• 在尝试开发超低延迟和/或高吞吐量应用程序时，没有人真正在使用Windows，这些天他们正在使用Linux。
• 如今，几乎所有性能测试和报告以及实际结果（即不仅仅是产品广告）都在Linux或BSD上进行（感谢Len成为先驱，并至少提供了一个参考点！）
• Windows上的UDP（标准套接字）是否比Linux上的快/慢？我还不能确定，必须自己做测试
• Windows上的高性能UDP（RIO与Netmap）比Linux上的快/慢吗？Linux 可以通过900MHz的单核轻松处理10Gb的全线速，在Windows 最好的情况下，对于1024个较大的UDP数据包，它可以提高43％或492kpps，即较小的bps数字可能会很大更糟糕的是，尽管pps的数字可能会上升（除非中断处理或其他内核空间开销是限制因素）。

至于为什么要使用Linux，这一定是因为开发封闭式系统（如将netmap或RIO更改为核心）的解决方案（将性能提升到极限）在使用Windows之类的封闭系统中几乎是不可能的，除非您的薪水恰好来自Redmond，或者您与Microsoft有一些特殊合同。这就是RIO是MS产品的原因。

最后，仅举几个极端的例子说明我在Linux领域发现的和正在发生的事情：

早在15年前，有些人已经在1GbE NIC上使用800 mHz的Pentium III CPU和133 mHz的前端总线接收680kpps的信号。 编辑：他们正在使用Click，它是绕过许多标准网络堆栈的内核模式路由器，即被“欺骗”。

2013年，Argon Design 设法获得

滴答交易延迟低至35ns [nano秒]

顺便说一句，他们还声称

今天，用于交易的绝大多数现有计算代码都是针对Linux x86处理器体系结构编写的。

和Argon使用Arista 7124FX开关，该开关（除了FPGA外）还具有操作系统

建立在标准Linux内核之上。

您肯定需要“测量”不同的配置和方案。可以使用2家公司提供的两套齿轮完成AFAIK。IXIA和Spirent。他们提供了基于硬件的流量生成器，能够以线速泵送流量。他们提供斜坡测试，您可以在其中检测特定系统崩溃的速度。这些设备很昂贵，但您可以租用它们。