《给力吧，x86》专题连载八：英特尔5520平台网络通信性能测试分析（下）
作者 老韩 | 2011-12-12 17:16 | 类型 研发动态, 科技普及, 网络安全, 行业动感, 通讯产品 | 26条用户评论 »
|
上一期连载内容中（见本报今年34期第28、29版），我们介绍了上海交通大学网络信息中心的老师们在流量分析与优化系统选型中面临的问题。那么，x86平台在万兆环境下能否稳定工作？现有平台的性能是否又能满足需求？针对种种疑虑，老师们对送测产品进行了长期、细致的测试验证工作。
性能初测通过 在吞吐量测试中，老师们只选择了64Byte和512Byte两种比较具有代表性的帧长。前者是对设备极限性能的考验，现网中绝少出现（个别DDoS攻击会在短时间内产生大量小包，对工作在4层以上的设备造成很大压力）；后者则比较接近现网中的平均包长（600-700Byte），测试结果具有比较强的参考价值。考虑到个别设备会在超过极限处理能力后性能大幅下降，丢包率远远超过理论值（通常丢包数量应等于测试流量减去极限处理能力），有着资深运维经验的老师们还特别考察了Panabit在过载时的性能表现。
表注：吞吐量、丢包率测试结果（4层，数据包有IP头/协议类型UDP） 从结果中可以看出，面对一系列苛刻的测试条件，由顶级英特尔5520平台所承载的Panabit应用层流量分析与优化系统还是表现出了不错的性能。在使用64Byte帧进行测试时，系统整体吞吐量达到20%，整体包转发速率为5.96Mpps；当使用512Byte帧时，系统整体吞吐量达到64%，整体包转发速率为3Mpps。测试结束后在Panabit提供的统计信息中可以看到，所有流量也被顺利识别为未知协议。而在使用略高于两个极限值的测试流量进行过载测试时，测试仪统计得到的丢包率也在预定范围内，系统整体运行稳定。
表注：吞吐量、丢包率测试结果（3层，数据包有IP头/协议类型None） 瓶颈究竟出现在哪个环节？是转发层面还是业务层面？老师们利用之前的环境，使用另一组测试用例进行了验证。这次测试仪发出的流量将不包含UDP头部，仅为带有IP头的3层报文。根据Panabit应用层流量分析与优化系统公布的运行逻辑，这样的流量从负责数据转发（I/O）的内核提交到做状态检测与应用协议识别控制的内核后，将只进行连接层面的处理，业务逻辑基本等同于工作在桥模式下的状态检测防火墙。在抛开繁重的应用协议识别的包袱后，系统的整体处理能力是否会有一个飞跃呢？测试得到的结果令人感到意外，当使用64Byte帧进行测试时，整机吞吐量仅比之前高出4个百分点；而当使用512Byte帧测试时，吞吐量没有发生任何变化。虽然目前无法判断状态检测引擎是不是瓶颈所在，但基本可以判定应用协议的识别控制并不是系统整体的瓶颈，x86处理器在计算能力方面的优势还是值得肯定的。而这一阶段的测试数据也让老师们相信，Panabit应用层流量分析与优化系统对于上海交通大学校园网目前的运行情况来说，也是能堪大任的。 5520平台深度分析 在征得老师们的许可后，我们在同样环境下使用久经考验的评估利器NCPBench 0.8进行了测试，得到了可以用做纵向对比的数据。在这个环节中，服务器上的两个万兆接口和每两个相邻的千兆接口被配置为网桥，在纯转发与简单业务两种模式下使用64Byte帧进行测试（NCPBench的功能介绍和使用方法见本报今年第16/17期51版）。
表注：NCPBench吞吐量测试结果 我们又得到了两组几乎一致的数据，无论是纯转发模式还是简单业务模式下，被测平台的吞吐量均为39.163%，包转发速率则接近14Mpps。还有一处值得注意：两种模式下，4个千兆接口间均能达到线速转发，两个万兆接口间则只能达到单向4Mpps、双向共8Mpps的转发速率。我们非常关注前者会对后者造成多大的影响，所以在最后单独对两个万兆接口进行了纯转发测试。此次得到的数据是单向5.12Mpps、双向共10.24Mpps，较之前有所上升，但与整机处理能力仍有不小的差距。需要说明的是，NCPBench允许测试者自行设定要使用处理器内核的数量，上述数据是在使用两个核情况下的测试结果。我们也尝试使用更多的内核数进行了测试，得到的数据基本相同，个别情况下还会略低。 这是个很有意思的现象，对瓶颈定位有着很大帮助。与Panabit“特定内核处理特定业务”的逻辑不同，NCPBench的业务模型采用SMP模式构建，每个内核都进行数据包转发与业务处理操作。理论上如果每个核都达到满负荷工作状态，纯转发模式时的性能会高于简单业务模式。所以我们从测试结果中只能得到这样的结论，即无论在哪种工作模式下，处理器内核的利用率都没有达到极限，即便只使用两个内核时也是如此。 在长期的测试工作中，处理器资源耗尽通常是系统整体瓶颈的惟一原因，而这种“喂不饱”处理器的情况，还是第一次出现。我们也曾怀疑性能瓶颈可能来自于NCPBench自带的网卡驱动，但在稍后进行的对英特尔Sandy Bridge平台的测试中，同样的驱动在一块同样基于英特尔82599EB网络控制器的网卡上带来了28Mpps的纯转发能力。所以，我们只能做出最遗憾的推测，即戴尔PowerEdge R710服务器的某个部分也许存在I/O方面的设计瓶颈。之所以不怀疑5520平台，是因为我们在另一个测试中，在一台采用E5550/4GB/82599EB配置的网络通信硬件平台上得到了两口间16Mpps、4口间超过22Mpps的测试数据。这也与我们经验中侧重于计算的服务器平台，在I/O方面逊于专注于通信业务的网络通信硬件平台的认识相吻合。 其实，即便是同样类型、同样配置的设备，在承载网络通信、安全这种时延敏感型业务时的表现也可能存在很大差异。在之前我们进行的基于Atom D525平台的评测过程中，就出现过来自不同厂商的配置完全一样的产品性能差异达40%的情况。我们无法对此做出更准确的解释，只能提醒广大用户和各厂商负责供应链的人员，在选型时一定要做更加细致的测试工作。 识别准确 稳定可靠 经过一系列测试，由英特尔5520平台承载的Panabit应用层流量分析与优化系统表现出了不错的性能水准，受到上海交通大学网络信息中心老师们的普遍认可。实际上，老师们对该系统在应用协议识别率及稳定性方面的测试早在去年底就已开始，他们使用另一台基于英特尔至强E5620处理器的服务器搭载Panabit，以旁路模式对两个万兆接口镜像而来的所有IPv4出口链路的上、下行流量进行了长期的监控分析。从老师们提供的统计资料中可以看出，未知协议所占流量在累计数据中所占的比重为2.8%，在10分钟统计数据中的所占比例也仅为3%，识别率堪称优秀。而在稳定性方面，资料显示该系统已连续运行超过168天，老师们也坦言没有出现过任何异常，只是在系统更新等人为操作时才会重启。
出于更加稳妥的考虑，老师们还是决定进行更长时间的旁路测试后，再讨论将其部署到网络边界。不过我们认为，在如此复杂的应用场景下长期稳定运行的事实，至少可以适当修正那些“x86架构产品稳定性不如专用系统”的论调。如果决定接入，硬件设备还要在可靠性方面满足更多的要求。例如现在工作在旁路模式下，可以不考虑接口的硬件Bypass，但当接入现网环境时，硬件Bypass特性就成为一条底线。服务器搭配多网卡的方式显然不能满足这一需求，我们建议老师们辅以专用的硬件Bypass设备，或直接选购支持该特性的x86网络通信硬件平台。 站在科研的角度，网络信息中心的老师们还提出了一些颇具价值的建议。例如针对前景被广为看好的OpenFlow，老师们建议Panabit增加在协议识别后输出Syslog信息的能力。这样一来，该系统就可以直接部署在一些基于OpenFlow搭建的网络环境中，为控制器提供基于应用层协议的策略配置能力。网络设备在并发连接方面的限制如今也需要突破，像本次测试版本中限定的600万并发连接数，仅用两台高性能服务器做端口扫描（模拟DDoS攻击）就可以打满，此时协议的正常识别就会受到影响。毫无疑问，这些来自科研领域兼一线用户的真知灼见，对产品的完善提高有着宝贵的指导意义。 测试后记 本次测试时间久、项目多，我们认为其中最有价值的内容当属老师们使用的测试方法。被测设备两端模拟大量MAC及IP地址后随机发送流量，可以快速制造出大量的新建连接和并发连接，对一切基于状态检测机制的设备造成较大的压力。即便是传统防火墙，也可能在连接的建立和拆除过程中遭遇性能瓶颈，其直接表现就是系统假死机（CPU占用率100%导致失去响应）或真死机/重启（如果系统架构有缺陷的话）。当连接信息足够多时，CPU在处理中也不得不频繁更新Cache中的数据，会对性能造成非常大的影响，许多高端x86架构产品选择Cache较大的至强处理器就是为了规避这一瓶颈。此外，如果使用比较少的流进行测试，业务处理时通常会走快速路径，而随机多流测试可以更好地模拟现网模型，充分评估设备处理慢速路径时的性能。根据我们以往的测试经验，不少安全设备在这种测试环境下性能会有数量级上的下降。 另一方面，我们在之前的下一代防火墙专题中曾经讨论过，使用UDP数据包进行吞吐量测试，不太适合于IPS、WAF等设备的评估，却很容易对流控、上网行为管理等一切基于应用层协议识别技术的设备造成极大的压力。因为目前来看，对UDP包的检测通常是应用协议识别引擎中的最长路径，而测试时构造出的UDP包又必然会被判断为未知协议类型，后继流量没有快速路径可走，设备应对其进行逐包分析。这一环节对硬件处理能力的需求，理论上远远超过状态检测，所以用户即便没有很强悍的测试仪表，也可以通过高性能PC/服务器加发包软件的方式自行测试。惟一需要注意的，是一定要在测试前验证协议识别的效果，保证协议识别引擎处于正常工作的状态。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   (3个打分， 平均：3.67 / 5) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
雁过留声
“《给力吧，x86》专题连载八：英特尔5520平台网络通信性能测试分析（下）”有26个回复
现网平均包长600-700字节好像不能这样理解。我印象中是因为现实IP网络流量模型的“双峰结构”，即64字节和1500字节各自占了40%以上，导致算下来平均每包长大约为1500的一半左右。因此实际测的时候，应该是发同等数量的包64B和1500B，而不是64B和600B。
64b都是tcp ack
1500都是p2p
纯转发的话pps越小，负载越轻。600没问题，1500就更没事了。
上图的“其它”（14%）和“未知流量”（3%)之间是什么关系？
采用多条流的测试是有代表意义的。以前仅是发单条流测试的情况，因为表项都被cache了，那都能很高。对于6Mpps的性能应该来说，也算不错，但以往动不动就说十几，二十Mpps的测试结论难免误导人。不过，对于高性能的转发设备来说，采用X86+外置网络及芯片+加速桥片的成本没有优势。但对于没有硬件开发能力的公司来说，是唯一的选择。
看到：分别在两个10G接口后端模拟了100个MAC地址和10万个IP地址. 我笑而不语。
1.如果是接 1M 个MAC 地址和 10M 个IP地址呢？
2.如果是ip fragment 攻击呢.
3. 80% packet 是 32B 的呢？
发回去重测吧，就这种测试法，设备只能用在内网环境了。
一项产品，不是完全看性能，重中之重的还要稳定性、可靠性，Panabit做得非常好！
两码事
用5690来做测试，不具有代表性，$1663的CPU价格，130w的功耗，不适合用在嵌入式通信系统。
如果前面关于CPU资源不是瓶颈的推论能站得住脚的话，那么这两代微架构里已上市的CPU里，感觉上SNB E3 1220L比较适合(纯粹从Intel官方指标分析)：20w的功耗，2核4线程，双通道1333，20根PCIE2.0的LANE，$189的价格，建议老韩有机会测试一下。
但是测试系统的NIC一定要直连CPU出的PCIE，决不能通过PCH，DMI 2.0才x4带宽是瓶颈。
$1663的CPU价格，130w的功耗 x86不是非常便宜吗？ 原来这么贵！！！！ 测一个贵的忽悠人，然后忽悠大家用便宜的，其实性能根本达不到？
HOLD ON, 这个CPU性价比一点也不好，后面会有对比。这也从另外一个方面说明服务器和工控机的差别。
“因为根据以往经验，许多安全产品在这样的环境下都会死机或者重启”
感觉稍微有那么一点夸张：）
呵呵MIPS别激动。其实，我是质疑评测平台的选择结果：“在英特尔尚未明确推出Sandy Bridge嵌入式解决方案的今天，基于5520芯片组的产品仍然是目前设备制造商与用户能够获取到的最高端x86平台。”当然，也许有免费赞助或者广告的原因，可以理解。
就事论事，5520并不是为嵌入式准备的，5690更不是嵌入式CPU，功耗角度怎么说也得是个“L”结尾的型号:) 另外，通信的高IO需求，其实并不适合2P、4P的多路系统，从软件角度做到2P=1P×2的性能太难，比上层APP难得多。最佳系统应该就是单颗CPU直连NIC，然后在这样一个简化的系统下得到pps/$的测试结果，估计能显现出出令人激动的效果。
其实原文中这一点已经点出核心了：“其实，即便是同样类型、同样配置的设备，在承载网络通信、安全这种时延敏感型业务时的表现也可能存在很大差异。”确实如此，x86也不等于市面上嘴边买一台server就能用，还是需要一些定制，当然这种定制的难度很低很容易可以做ODM
硬件平台是用户自己采购的，也许一开始并没有打算买来做这个用。
老师们其实很期待Sandy Bridge，不过这个专题连载第一篇是2月份刊登的，5520也是夏天的事了，那个时候还没有SNB的服务器和NCP可买。
在我接触过的行业用户里，SJTU网络中心的老师实力很强。测试模型是他们自己定的，我认为完全应用环境的抽象。
用户自己的标前测试，没啥商业因素在里头，写起来就是爽。用户说好，厂商就赚了；用户说不好，厂商也没法去“公关”。
这个协议识别的类型似乎少的可怜，业界的水平应该是500-1000种的水准，实现上，几个协议的识别是很容易优化的，但协议种类到了一定阶段，性能提升很难做。
楼上的，图片里的协议只是大类。建议你在胡咧咧之前先去人家网站看看产品的介绍，省得我还得冒着被当作五毛的危险来喷你。
1，协议识别测试未知协议所占流量在累计数据中所占的比重为2.8%，准确率多大呢，这个要单机装多应用多协议混合测试才能测试出真正能识别多少协议，笼统说有啥意义呢，广域网中本来无效流量就很多，难道这设备能看见单个syn包就能识别出是啥协议？太神了
2，对于接收转发，主要功劳应该归于intel 82599芯片，82599 RSS功能按流分配流量到每个cpu核心上。修改个多核0拷贝82599网卡驱动就可以做到，intel设计这芯片可是线速的
楼上的
1）关于协议准确率，我们网站上有免费的标准版，你装个试试就知道了。我们不敢保证100%准确，但是Panabit识别的准确率应该还是不错的。有大量的免费用户在不同的网络环境中使用，是经过大量检验的。准确率从理论上是没法保证的，只能是尽力而为。
2）“广域网中本来无效流量就很多”，这话不够严谨，什么叫“无效流量”，什么样的网络才是你所谓“广域网”。运营商的那些网管和买的那些设备可不是光在那儿吃素的。另外，即使是“无效流量”，也得通过软件发出去，是软件发出去的，就总有或多或少的特征。所以从协议分析角度而言，没有你所谓的“无效流量”一说。
3）关于多核zero copy问题，不是你用zero copy就一定能将性能做上去，驱动要做到极致，需要考虑网卡和CPU的并行处理协调能力。坦白说，目前我们还做不到在一个82599芯片内的两个PORT之间双向20G小包线速，我相信82599是可以做到的，只是我们功力不够而已，还需要继续努力。
回复 真不明白
下次在马桶把你的牙刷干净，嘴洗干净再来说话，五你妹，给你说说观点，你来耍流氓，脑惨一个。
所谓成本，其实是应该从更广泛的角度去考虑，优秀的OS当然能推动硬件发挥出最优的状态，如果硬用类似82599去堆转发效率，那直接用linux协议栈好了。
82599的rss在MC/MP环境下是非常有用的。没有RSS，CPU core需要软件再调度一次。
感谢Panabit的答复，我说的无效流量，比如攻击包，对方主机不存在的连接请求包等，总的来说网络上存在很小部分流量是无效流量，也就是还没有传输应用的负载数据的数据流，另外非公开的私有网络应用也应该识别不了的.我只是觉得未识别流量只有2.8%，如果指应用识别的话，不大可能。
panabit的识别率绝对是领先性的，而且其识别算法的是多重的状态机制去鉴证，而传统的一些，这点小弟是十分佩服。
各类应用的复杂程度，要找到一个合适的框架去解决流量匹配问题不是这么简单的事。我猜测要做到这种效率，主要还是靠四元组或者五元组的状态匹配。
楼上的，这个图貌不是你所谓的“广域网”流量吧
我不认为这个平台能做到82599线速，用sandybridge有可能，1300wpps是个坎，e5550两组万兆口可做到40mpps以上，对panabit的识别率到是很佩服的
变强的是网卡芯片和总线速度，跟cpu有很大关系吗？
进步真快啊！记得前两年，千兆线速都没实现那。