测试一：云主机网络带宽性能 原创

云主机网络带宽性能

公有云网络应用，首先要考虑到的就是带宽。不同配置云主机，所能提供的网络数据转发能力，自然也就成了云主机网络应用测试的首选项目。

在本次测试中，至顶网将测试的重点放在了云主机的虚拟网络端口之上。

（无论是在公有还是私有的云计算系统之中，均离不开虚拟网络端口对应用数据进行转发。了解在不同配置下，云主机虚拟网络端口应用处理能力，以此作为基准，可以对整套云计算系统应用性能进行分析。）

本次测试中，针对目前Web应用中最常用的2核4G、4核8G和这几家公有云厂商不需要提交工单时可选择的最高配CPU核数云主机（核心数与内存比为1：2）进行了测试。

测试的数据包大小定在了64Byet、512Byte、1518Byte和不限数据包大小时最大数据缓冲的文件传输性能。

【附注：考虚到阿里云新建数据中心服务器采用25G网络互连，与其它厂家的万兆（10G）网络性能差距过大。为了公平起见，在本次测试中，未选择阿里云新建25G数据中心的云主机进行评测。】

云主机网络带宽测试结果如下：

 

云主机网络带宽测试结果线图

 

云主机网络带宽测试结果（Mbps）

 64Byte：腾讯云与青云不相伯仲，但测试结果存疑

 64Byte是RFC2544测试中所定义的最小测试包长。采用64Byte的包长进行测试，主要目的是来看一下不同配置云主机的数据包转发能力。

从上面的测试图表中我们可以看出，在64Byte网络带宽测试中，最好成绩为腾讯云4核8G云主机，传输带宽可以达到1115.11Mbps。最低为阿里云32核64G云主机，传输带宽为310.86Mbps。除阿里云外，其它三家云主机厂商的云主机64Byte小包的转发性能基本都在1Gbps左右。但这就产生了一个问题：

 数据包转发资源规划问题

 在云计算的虚拟网络之中，数据包的转发是依赖于CPU这个通用处理器进行处理的。然而作为一个通用处理器，CPU在处理数据包转发的时候，效率并不是很高。过高的数据包转发，对CPU的处理能力占用，非常可观。

然而通过随后的大包网络带宽测试可以了解，百度云、腾讯云、青云最高也就是2Gbps左右的水平。小包时如此高的转发性能，对计算资源造成的浪费相对较高。

为了对测试结果进行验证，我们又对阿里云、百度云、腾讯云、青云的虚拟网络端口重新测试并进行端口流量和数据包统计。

阿里云64Byte测试数据包统计截图

百度云64Byte测试数据包统计截图

 腾讯云64Byte测试数据包统计截图

 

青云64Byte测试数据包统计截图

通过虚拟端口数据包统计我们可以了解，64Byte文件传输中带宽最低的阿里云云主机的数据包转发速率反而最高，达到30万PPS左右。转发带宽最高的腾讯云主机的数据包转发速率只能列到第二位，转发速率在15.6万PPS左右。按照物理千兆带宽64Byte小包线速1.488MPPS（148.8万PPS）计算，除阿里云外，其它公有云厂商64Byte小文件数据传输带宽与其转发速率并不相符。

 问题分析

 实际上，当前的测试结果已经是至顶网第二次对这几家公有云主机进行测试而取得的。在第一次时，64Byet小包测试中，阿里云云主机也曾得到过1.1Gbps左右的测试成绩，但在向各家云主机厂商反馈测试结果时，阿里云就即刻指出，测试结果与阿里云云主机处理性能不符。

原因是为减轻虚拟网络数据转发负担，在数据包转发时，虚拟网络会自动对数据包进行合并（将TCP的较小数据包合并成一个大数据包后向目的地址发出）这样在进行小包测试时，就会出现这种“扩包”现象，一个小数据包被虚拟网络打成一个大数据包转发，因此虚拟网络传输时网络带宽自然就大大增加。

在UDP传输时，由于不带传输状态，所以UDP传输时不存在这种数据包归并现象，这一点同样可以在TCP与UDP的传输性能对比中加以佐证，在进行同样包长的虚拟网络性能测试中，TCP传输性能往往要好于UDP传输性能；而置于传统网络环境中，UDP的传输性能则会表现的更好。

然而考虑到在当前的网络环境下，数据传输还是以TCP协议为主，而UDP则更多的用于一些对网络传输可靠性要求不高的音、视频数据传输之中。因此，在本次测试中，还是选用了在TCP协议中的网络转发性能进行评估。

在本次测试中，我们试图通过Netperf加上-D参数（-D 参数的含义是：对本地与远端系统的socket设置TCP_NODELAY选项，其目的是快速准确发包），对这个问题进行规避。但是从当前的测试结果来看，除阿里云在测试中的转发速率与转发带宽相匹配外，其它云主机小包数据传输还有很明显的数据包合包（小包合并成大包）现象出现。因此在测试中，出现了64Bytes小包测试时数据包转发性能与传输带宽不匹配的情况。（有关转发速率与数据包合包的关系，至顶网还会再找个时间，更进一步去进行了解。）

  512Byte-Max：云主机网络带宽应当如何规划

 在虚拟网络中，云主机的网络带宽应当如何设置才会比较合理？为此，至顶网又分别对512Byte、1518Bytes以及虚拟网络可允许的最大数据缓冲文件传输性能进行了测试。

采用512Byte数据包长进行测试，是因为在以往传统网络及网络安全产品测试中发现，512Byte最接近实际网络应用中的平均数据包长（约700-800Byte）。用它测试，可以比较真实反映传统网络中实际的带宽处理能力。于是在虚拟网络测试中，还继续沿用了这个测试包长进行测试。但虚拟网络TCP传输具有合包现象、而且最大包长也和传统网络有所不同。因此虚拟网络平均包长还有待今后进行更多的虚拟网络应用分析来确定。期望那时候，可以得到更加明确的虚拟网络数据包转发速率实际应用情况。

从512Byet开始，这些云主机网络带宽性能明显分为两种类型：阿里云云主机与非阿里云云主机。

 阿里云

 

 从512Byte起，本次测试中的阿里云主机网络带宽就开始出现分层，2核4G云主机的网络带宽始终保持在1.1Gbps左右，4核8G云主机的网络带宽在1.6Gbps左右，而32核64G云主机在512Byte时在2Gbps左右（注：在本项测试中，只开启Netperf的单进程进行测试，导致测试压力的不足，小数据包流量有所下降），1518-Max时达到6.5Gbps左右。从当前测试结果来看，阿里云对不同配置的云主机网络带宽，进行了细致的划分，云主机的配置越高，分配的网络带宽也得到了相应的增长。

 从作者个人角度来看，拖服务器后腿最严重的，实际上要数网络带宽。早在03、04年的时候，本人开始对服务器的网络应用能力进行测试，那个时候千兆网络接口就已经出现了。而到现如今，服务器的处理器无论是从主频，还是从处理器核数上，都有了飞速的增长，而千兆的网络接口却依然雷打不动的固化在服务器之上。在作者看来，网络传输能力与应用处理性能的不匹配是间接推动服务器虚拟化，乃至于目前云计算技术发展的一个重要原因……

能力越大，责任也就越大。如果用户云主机主要是进行Web类应用处理的时候，云主机的计算能力越高，所需要的网络带宽自然也需要相应的增加。这样一来也就不难理解阿里云云主机的网络带宽，在不同的配置之下也会有所不同的原因了。至于这个带宽配置是否合理，在接下来的应用连接性能测试中，我们至顶网还会更进一步的去进行分析。

（*有关阿里云32核云主机的网络带宽在512Bytes时，仅达到了2Gbps的问题，我们会在下面“多队列网卡与单进程测试”的技术分析时会再详细进行分析。）

  百度云、腾讯云、青云

 

之所以将其它三家云主机厂商放到一起进行分析，是因为从512Bytes起，这些云主机厂商不同配置的云主机网络带宽就基本处于“一个水平线”上，基本都在1Gbps到2Gbps之间徘徊。

实际上在第一次对云主机网络性能测试的时候，百度云云主机的网络带宽是呈现全放开的一种状态，各种配置云主机的最大网络带宽均可以达到5Gbps以上。但是当第一次结果反馈回去之后，现在已经迅速将网络带宽调整到了950Mbps左右。

 

 百度云云主机第一次网络带宽测试结果

 上面谈到过，更高性能的云主机，需要有更高的网络带宽对其应用进行保障。但百度云、腾讯云和青云并未向云主机提供更高的网络带宽是出于什么样的考虑呢？在这里想对云主机网络带宽设置，更进一步的来讨论一下：

还是以目前常见的Web应用为例，在目前的云计算系统中，要想对大流量、高并发的网络应用请求进行处理的时候，通常是采用负载均衡的方式，将应用请求平均分配到多个云主机上分别进行处理。在具有多个计算核心的云主机内部也是一样，需要将应用请求分发到每个计算核心之上，才可以将多核云主机的处理能力充分的发挥出来。

是通过一条高带宽的虚拟网络将应用请求发送到一个高处理能力的多核云主机上进行处理？还是通过多条较低带宽的虚拟网络，将应用请求分发到多个处理能力较低的云主机上通过负载均衡的方式处理？这个问题还需要根据具体的应用需求去具体的分析。

相对来说，经过多年技术发展完善的负载均衡技术，在网络传输稳定性和可靠性方面都有很好的技术保障。如果用户应用的计算量并不是很大的话，通过负载均衡将访问流量分配到较低配置和带宽的云主机上，在技术可行性上会更加的适宜。

当然，像腾讯云32核心64G内存云主机配置下，还只为云主机配置1Gbps左右的带宽，是为了解决什么应用需求，还需要更进一步去研究一下。

此外，由于青云高配置云主机需要另外提交“工单”进行配置，与此次想对各厂家云主机“本色”进行测试的目标不符，因此未进行测试。

 

 多队列网卡与单进程测试

在上面的结果分析中，还有一个细节没有分析到，那就是选测的青云云主机虽然只有两种配置，确有4个测试成绩，其中两个标注了“多网卡”。

这里的“多网卡”全称应是“多队列网卡”：多队列网卡技术，最初是用来解决网络IO QoS （quality of service）问题的，后来随着网络IO带宽的不断提升，单核CPU不能完全满足网卡的需求，通过多队列网卡驱动的支持，将各个队列通过中断绑定到不同的核上，以满足网卡的需求。

 

在青云通过控制台创建云主机的时候，可以很轻易的通过点选“网卡多队列”选项的方式，对多队列网卡功能进行应用。

 

 可是从当前对青云云主机的测试结果来看，青云云主机在加载多队列网卡功能后，64Byte小包带宽提升有限，但大包网络带宽反而受到了影响。

 初步分析，这是由于Netperf这个测试命令在测试过程中，只打开了一个进程，因此无法将数据转发请求平均分配到多个网卡上进行处理的原因。但是当我们准备加大测试时长，并开启多个Netperf进程进行测试的时候，却被青云的网络安全策略所拦阻，无法继续进行评测。

 

多进程——来自阿里的复测

 在第一次测试结束后，我们曾将结果发给这几家云计算厂商进行确认。没想到很快阿里方面就传来了反馈“测试方法不能反映阿里云云主机采用多队列网卡技术后的最大性能，并愿意提供阿里内部测试方法进行复测”。可以接触到更多评测技术，当然是我们至顶网所喜闻乐见的一个事情，于是又开始了一次针对阿里云32核64G内存云主机网络带宽和连接的复测活动。

原本我们考虑到多线程问题，也曾经尝试启用多个云主机并使用iperf测试工具来对网络带宽进行测试，然而这样测试的结果统计问题并没有很好的得到解决。因此这种测试的成绩也未对外放出。而且由于是在公有云上进行测试，在现网环境中进行性能测试，更需要小心翼翼，即便是在一个VPC网络内部，也怕会对公有云网络造成什么不良的影响。

 可阿里提供的测试方案要激进的多，通过编写脚本起100个netperf测试线程，在200秒的测试时间内，同时对被测端进行测试。而结果统计是通过查看被测端口流量的方式。

 

Netperf单字节TCP转发性能测试虚拟端口数据包速率统计

 

Netperf单字节UDP转发性能测试虚拟端口数据包速率统计

为了方便直观的对数据包转发性能进行统计，在本项测试中，将数据包转发速率的测试字节大小定在了1Byte，通过被测端口数据包转发统计可以了解，阿里云32核64G云主机虚拟网络端口的TCP转发性能平均在2.2Mpps以上，UDP的数据包转发性能更可以提升至2.5Mpps。这样的转发性能基本上可以满足64Byte小包接近2G带宽的数据转发需求。以此推断，在256Byte就可以满足8G网络带宽数据传输。阿里云32核64G云主机的网络带宽限制是在6.5Gbps（在上面不同云主机网络带宽测试中已经验证，就不再重复测试了）左右来分析，其可以提供充足的数据包转发能力满足网络数据传输需求。

通过这个测试，也让我们对阿里云的虚拟网络，在高转发速率下的网络健壮性，有了更加充分的体验。