青云云主机青云服务器官网

在上一篇文章“主流公有云产品功能性分析”中，我们对这些云主机厂商自身发布的功能性指标进行了一次简单的分析对比。而公有云主机的实际应用性能，还是无法从中进行体现。为此至顶网又策划了本次国内主流公有云主机的网络应用性能测试活动。在本次活动中，至顶网同样选择的是对阿里云、百度云、腾讯云和青云这几家主流云计算厂商的公有云产品进行评测。

网络应用性能测试，是通过模拟真实的网络应用请求，对网络产品的实际网络应用处理能力进行评测。通过网络应用测试，应该可以完全真实的评估出网络产品在现实应用中的实际应用情况。当前全球主流的网络应用性能测试仪表提供商，有思博伦和IXIA两家。

早在十几年前，这两个厂商就开始向网络及网络安全厂商提供网络应用性能的测试解决方案。当云计算、SDN/NFV技术兴起后，思博伦和IXIA公司也相应推出了针对虚拟化产品的网络应用性能测试产品。

在本次测试初期，也曾规划将他们推出的虚拟化网络应用测试工具安装到本次测试的云主机之中。（可参见“公有云主机网络应用性能公开测试方案”）从而可以对“应用请求处理速率”、“应用请求响应时延”、“并发用户数”、“应用流量”这些应用性能评估的关键指标进行最直接的评测。

然而理想很丰满，现实太骨感。在经过了多次尝试之后，这两款软件在云主机上的安装还是以失败告终。无奈之下，只能退而求其次，采用在Linux上使用的Netperf工具完成本次测试工作。

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

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

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

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

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

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

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

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

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

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

通过虚拟端口数据包统计我们可以了解，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、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个测试成绩，其中两个标注了“多网卡”。

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

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

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

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

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

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

可阿里提供的测试方案要激进的多，通过编写脚本起100