《给力吧,x86》专题连载三:x86平台网络应用效能实测

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




弯曲评论现在的影响力很大,甚至能吸引到一些行业用户的关注(潜水居多)。本文就是《给力吧,x86(1)——11月10日测试记录》一文刊登后,用户直接与我们沟通进行的一次测试合作的副产品。这是一个良好的开端,后续还有与其他用户联合进行的更大、更深入、更给力的测试,敬请关注。

==============================================================

前两期连载中,我们简单回顾了x86平台在网络产品中的应用历程,又逐一分析了其面向不同用户群体的硬件供应模式。实践是检验真理的唯一标准,本期就让我们走进现实中,借助近期的一次测试,看看在网络技术及应用高速发展的今天,x86平台对业务的承载能力究竟如何。

虽然一些业内人士已经看到x86平台的发展,认为其将在网络领域有所斩获,但对于普通用户来说,再次接受x86平台有着很大的难度。一方面,这个曾经不太适合做网络业务处理的硬件平台为许多用户留下过不好的应用体验;另一方面,一些厂商长期对x86架构并不客观的宣导,也加深了其在用户心中的负面印象。

先入为主的误会

我们在之前的调研中发现,抱有这种看法的用户并不在少数。北京市某学校信息中心负责人李老师就是一个典型代表,虽然他在目前进行的流控产品选型中比较中意连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统,却因其运行在x86平台上而犹豫不决。

“我们一直用着一台x86架构的UTM产品,效果越来越不好。”李老师介绍说,“以前网络负载不大时,设备运行没有任何问题;现在越来越多的教学、科研任务要通过网络进行,学校网络出口的百兆带宽经常被占满,UTM运行也变得不稳定。”令人没有想到的是,他紧接着又说出一个令我们很难理解的结论,“看来,x86平台也就是这个样子了。”

x86架构与网络运行不稳定有直接关系?实验室工程师习惯以量化的数据去看待问题,自然无法认同李老师的推断。在他的协助下,我们走进该校信息中心,对网络运行情况进行了实地考察。经过分析,我们发现造成学校网络出口拥塞的主要原因大致有三:其一是在线课件播放系统产生的数据流量,由于学生分布在不同校区,远程教学会在上课时段对网络造成比较大的压力。其二是学校周边视频监控的数据上传流量,根据教委要求,为加强校园安全工作,各学校的视频监控数据需实时汇总到教委信息中心,以便对突发事件做到事前预警、事中监控及事后取证。李老师所在的学校需要实时上传4路监控视频,这也是该校网络上行带宽占用率居高不下的原因之一。其三则是P2P、在线视频等非业务应用产生的流量,此类应用会无限制地占用网络带宽,是每一个网络管理员都非常头疼的问题。我们在分析报表中看到,以迅雷为代表的下载应用在网络使用高峰期一度抢占了70%左右的带宽,严重影响了该校教学工作的正常开展。

根据分析得到的数据,我们建议李老师对UTM上的安全策略进行了调整,不再对远程教学与视频监控相关的流量进行应用层面的安全防护。由于它们都是可信流量,修改过的访问控制策略非但不会造成安全隐患,还能有效降低UTM的负载。很快,我们看到设备的CPU占用率显著下降,内网用户访问网络的延迟也回到相对合理的水平,x86“不行”的误会也就此得到解除。但对于非业务流量的控制需求,该校主出口使用的这台国外某品牌的UTM产品并没有足够的本土化保障,对国内主流应用的支持力度相对薄弱,无法进行有效的控制。可以说,流控产品的部署势在必行。

标前测试:大放异彩

虽然解决了UTM运行不稳定的问题,李老师所在的信息中心管理团队还是对x86架构产品存有疑虑,不愿直接将设备接入实际环境进行测试。这一点大家都能理解,毕竟学校网络承担着大量的教学、科研任务,万一出现意外,后果将不堪设想。在我们看来,李老师所在团队目前所需要的,是一次客观、严谨的标前测试。实际上,这一环节已经被国内越来越多的用户所认可,因为是否选购产品,或者是否再接入实际环境测试,都可以用标前测试得到的量化数据作为决策依据。

在实验室合作伙伴思博伦通信的支持下,我们与李老师所在团队合作,于近日测试了他们关注的Panabit应用层流量管理系统。该产品运行在x86平台上,拥有优秀的协议识别率及性能。商务模式方面,Panabit可以通过软件授权或服务的形式进行交付,给用户自行选择硬件的自由,还可以节省大量开支。李老师这次带来的硬件,就是供应商基于该校网络实际情况,推荐的一款带有6个千兆电口的基于Atom N270的x86网络通信硬件平台。

Atom N270?实验室工程师们感到难以置信。要知道,流控引擎是在DPI(Deep Packet Inspection,深度包检测)的基础上结合多种技术发展而来,属于处理模型相对复杂的一类业务应用,对硬件平台的计算能力有着相当高的要求。而Atom N270是什么级别的产品?放在上网本里也算是两代之前的配置了,它真能满足百兆级别应用层流量管理的需求?

诸多疑问化作动力,催使我们立即开始了测试。被测设备预装了Panabit 10.10专业版,开启了应用层流量分析,作用于4个千兆口绑定成的两组桥。根据联合制定的测试方案,我们首先对带业务情况下的吞吐量、延迟进行了测试。虽然常用的UDP测试流量对于IPS、WAF等应用层安全设备来说意义不大,对流控产品测试却有着十分现实的意义——据统计,目前互联网中占流量比例最大的是在线视频应用(在教育、网吧等行业中比例数字更为惊人),它们其中大多数都使用了UDP传输,且数据包偏小。测试结果令人震惊,当我们单独测试1组桥的性能时,该平台64Byte帧的吞吐量达到41%,也就是800多兆的处理能力。当帧长逐渐增加时,吞吐量也呈线性增长,并在1518Byte时达到线速。此时最大的平均延迟,也仅为68微秒。而在同时对2组桥的测试中,设备的整体吞吐量又有所增加,在256Byte时就已拥有接近2G的性能。我们也利用全部4个接口测试了该产品的链接处理能力,当链接的Timeout时间设为0时,Avalanche测得的稳定值在90000左右,峰值为90014CPS(HTTP)。这一次的数据体现出了设备的极限性能,根据以往经验,其表现完全可以胜任普通千兆接入环境中的应用。

测试项·配置

帧长度

2个GE做1组桥

(100%=2Gbps)

4个GE做2组桥

(100%=4Gbps)

吞吐 平均延迟 吞吐 平均延迟
64 Byte 41.19% 24 us 22.28% 34 us
128 Byte 54.42% 24 us 37.37% 38 us
256 Byte 67.65% 24 us 48.08% 42 us
512 Byte 82.10% 37 us 52.35% 42 us
1024 Byte 92.02% 76 us 53.38% 54 us
1280 Byte 95.58% 64 us 55.37% 58 us
1518 Byte 100% 68 us 56.92% 68 us

有了这些测试数据,老师们基本放下心来,将设备接入实际环境中进行了长时间的测试。对于流控设备上线后的效果,李老师给予了充分的肯定:“业务流量控制住了,学校网络出口的流量也就下来了,UTM的负载就更小了。”而在稳定性方面,他也坦言没有遇到过任何异常情况,不过我们仍然建议做更长时间的测试,以便进一步考察x86网络通信硬件平台长期不间断运行的效果。

后记:广阔天地 大有作为

从测试结果中可以看出,x86平台的网络业务处理能力确实有了长足的进步。目前,在英特尔面向网络应用的嵌入式产品线中,Atom N270是最低端的一款产品,都有着如此强大的处理能力。随着网络通信和信息安全业务的关注点逐步向应用层迁移,x86平台的优势将会越来越明显。当然,现有基于x86架构的产品仍不足以在高端市场和基于专用网络通信处理平台的产品竞争,但在其他诸多领域内,x86已经表现出了一定的竞争力。对开源系统良好的支持、海量的软件资源、较低的开发难度、价格优势和易获取性,这些都是其取胜的砝码。是否有点眼熟?没错,如果哪天基于x86架构的网络通信和信息安全产品(至少是中低端)开始山寨化,大可不必感到奇怪。

(1个打分, 平均:5.00 / 5)

雁过留声

“《给力吧,x86》专题连载三:x86平台网络应用效能实测”有11个回复

  1. zhh 于 2011-12-08 5:04 下午

    谢谢老韩不余余力的大力推广X86平台在网络方面的应用,在可预期的将来,随着网络安全逐渐向应用层转换,x86平台会有更大的发展。

  2. zzz 于 2011-12-08 5:22 下午

    X86再给力也就只在千兆性能了,就目前来看,国内运营商都在扩容带宽,这种设备注定还是不会大有作为,就运营商层面来看,这样的东西是不会入眼的,但中小企业还是能满足的了

  3. willchen 于 2011-12-08 6:12 下午

    看了这篇文章感触很多,很幸运这个用户能有第三方机构为其参谋选型,而且也有测试的机会。但目前大部分用户在真正买到设备之前只能也只想看到彩页等厂商单方面宣传资料(特别是政府采购)。而这个行业缺乏标准的事实造就了大量虚假指标,搞得用户往往不是买到了超出其实际需求的产品,就是买到了虚高指标,实际不能满足需求的产品。
    其实,用不用x86,应该是厂商考虑的事儿,而不应该由客户选择。客户应更加关注其需求本质。该项目中还可以看出,用户缺乏横向对比。而现实也不允许大部分客户作横向对比,只有运营商或行业大客户才可能在某些集采项目中搞些对比测试。而是否这款产品就是最满足用户需求的?有没有更好的?用户其实并不清楚。

  4. willchen 于 2011-12-08 6:16 下午

    续上,就眼前这个项目来说,其实UTM与流控的组合未必就是最佳方案。考虑到校园网P2P和视频大量存在的现实,光靠阻挡只会降低用户网络使用满意度,应该考虑部署缓存或加速设备,疏堵结合才是更优方案。

  5. 新手 于 2011-12-08 6:32 下午

    panabit果然够彪悍。目前有10GE产品没?用的哪款CPU?

  6. Panabit 于 2011-12-08 6:53 下午

    回楼上,10G产品早就有了,已经在一些一二级运营商部署了不少。

  7. blue 于 2011-12-08 8:16 下午

    续上,就眼前这个项目来说,其实UTM与流控的组合未必就是最佳方案。考虑到校园网P2P和视频大量存在的现实,光靠阻挡只会降低用户网络使用满意度,应该考虑部署缓存或加速设备,疏堵结合才是更优方案。

    顶,“控”太暴力

  8. kevint 于 2011-12-09 5:17 下午

    atom成本性能功耗全线输给arm似乎已经无须争论。中低端的山寨化已经从ARM开始了吧

    panabit的核心价值是什么?从atom到xeon的scalability?

  9. ray 于 2011-12-29 12:04 上午

    x86的通用性好,但功耗的确是个问题,特别是在大规模运营上,功耗是个问题。一切会随着芯片工艺提升而得到解决,但应该看到x86体系的特点,不强力为之,再有需要考虑产品的性价比。让x86再飞一会……

  10. 小猎 于 2012-01-04 12:52 上午

    猎头职位安全领域:网站安全经理、LinuxC开发工程师/项目经理(防火墙、IPS、VPN、流控、桌面安全、交换机、路由器等)、测试、产品经理、行研、架构、杭州办事处区域经理………小猎来给乃们松松土,年后机会更多,有考虑新机会意向的提早联系我啦。QQ2594873804 邮箱2594873804@qq.com 挖的墙角太多,公司邮箱不方便留啦,见谅哦

  11. ATOM 于 2012-01-05 9:04 下午

    http://news.imeigu.com/a/1325813331655.html 又一个大客户放弃ATOM