测试二：云主机网络连接能力评估 原创

云主机网络连接能力评估

 当前云计算网络系统，是基于软件定义网络（SDN）进行的“转发”与“控制”分离。对于上述几个公有云的云主机转发能力，通过网络带宽我们已经有了一个大致的了解。而控制能力还需要去更进一步进行研究。

 对于“控制”而言，实际上就是在带宽这条大马路上划出一条条行车的车道。车道太少，需要上路的车都要排队，会影响传输效率。车道太多，马路上车辆拥挤，同样会对网络传输造成不良的影响。

 当前这几个云厂商的网络控制能力如何？至顶网通过云主机的网络连接建立能力同样进行了一次检测。

 在测试中，至顶网选用的是Netperf加载TCP_RR和TCP_CRR参数，对云主机的网络连接能力进行测试。为了了解在不同文件大小情况下，云主机的连接建立情况，本次测试还将本地和远端系统的Socket发送与接收缓冲大小分别设置为64Bytes、1024Byte、10240Byte、102400Byte以及1024000Byte。

 首先要来谈一下的是Netperf测试所存在的问题：各厂商云主机配置不同，网络连接测试的成绩十分相近。在大文件应用传输时，如果网络带宽相同，受到带宽的限制，云主机的网络连接测试成绩相近这很好理解。但是不同配置不同带宽的云主机，网络连接性能如此相近就只能说明一件事情：应用请求没有平均分配到各个计算核心上去。这个测试所体现的，很有可能只是单个CPU内核的网络应用处理能力。

 即便是单个核心，也不妨碍我们去对这个云主机的网络连接处理情况进行一下分析。下面我们就去具体的分析一下：

 Netperf加载TCP_RR参数测试

同带宽测试一样，在应用连接中，64Byte的数据传输也是属于“神话”这个级别——只会在传说中存在，在实际应用中用户是万万不可能见到的。（如果真出现的话，那就是CC或DDoS了。）之所以64Byte甚至1Byte的应用连接测试至今还在使用，是因为通过对作为TCP/IP定义的最小包长测试，可以了解产品的最大处理性能。在网络带宽的测试中，了解的是数据包转发的处理能力。而在连接性能测试中，同样也可以对网络连接建立能力进行评估。并且由于连接建立通常是交由CPU进行处理，因此在网络应用性能测试中，最大连接处理能力，同样也是对服务器网络应用计算能力的一项重要评估。

现在我们就通过Netperf加载TCP_RR和TCP_CRR参数来了解一下这几个云主机“疑似”单核的最大网络连接处理性能。

为什么说是“疑似”单核，是因为测试结果有些让人困惑。首先看连接建立能力最强的阿里云主机，64Byte时连接建立能力均在每秒1万连接以上这让其当仁不让的站上了连接处理能力最强的第一梯队。然而随着内核数量的提升，云主机处理性能会有一定幅度的下降，不过这到可以理解，多核处理器在处理应用请求的时候本身就要先做一个判定，是用哪一个内核去进行处理，即便是一个单进程的处理任务只划分到其中一个内核去进行处理，也需要进行一下判断和计算资源分配，这自然也会消耗掉一定的处理时间，处理能力自然会有所下降。

但是在青云的云主机上，情况正好相反，4核8G云主机的连接处理能力好于2核4G的云主机，但性能又不是成倍的提升，64Byte每秒1万连接所占带宽仅在5Mbps左右，也远没有超出网络带宽限制范围之外，这样的结果到底是在云系统中进行了连接数限制，还有有其它原因？还有待进一步去进行了解。

从云主机网络连接TCP_RR测试结果线图可以看出，除阿里云云主机外，其他云主机网络连接建立能力从2048Byte开始出现大幅下降。而此时，即便是按连接处理能力最高的阿里云6500以上的网络连接建立能力计算，其网络传输带宽也未能超过540Mbps，可以确定并不是因为网络带宽的限制导致了网络连接建立能力的下降。

那么是由于数据包转发性能设置过高，造成的应用连接处理能力下降，还是这些云主机在处理多数据包时CPU处理能力降低？（10240Byte及以后的测试文件大小超出了虚拟网络的最大数据缓冲文件大小，会分成多个数据包进行转发）。这种情况对实际网络应用会造成什么样的影响？这些问题还需要在今后深入研究。

Netperf加载TCP_CRR参数测试

按照Netperf的解释，采用TCP_CRR参数，会在连接数据传输完毕后，将连接进行断开。更像是实际网络中HTTP协议传输数据时的情况。由于每次连接都需要重新进行建立，对服务器的应用负载会更大一些。

在TCP_CRR的测试过程中我们发现在64Bytes到10240Byte时，不同云主机的连接处理性能出现了明显的“分层”现象。从云主机网络连接TCP_CRR测试结果线图中我们可以清楚的看出，处于最顶层的是阿里云2核4G、4核8G、32核64G云主机。下方是青云的4核8G和2核4G云主机。再下面是腾讯云的32核64G、4核8G和2核4G云主机。而百度云的云主机处于最低下的位置。

这个排序，应该可以比较清晰的体现出不同云主机在“单核”时的网络应用处理能力了。

原本计划通过1024Byte-1024000Byte这些不同大小文件，在进行连接测试的过程中，同样对云主机的数据传输性能再进行一下分析。然而由于测试工具Netperf的单线程测试能力，并不能将应用连接很好的分配到云主机的多核处理器之上，因此云主机有限的处理能力，不能很好的对网络数据传输进行处理。

但是1024000Byte这种接近1MBytes的文件大小对于云主机的处理能力要求已经是十分的有限了，可是在测试结果中百度云和腾讯云的云主机依然未达到1000Mbps的网络传输带宽，这样的应用处理能力就让人十分费解了。而且在这种大文件之下，腾讯云的连接处理能力会被百度云进行反超，这个问题，还有待更进一步了解。

注：阿里云在2核4G云主机上133TPS的成绩应该是受到其1.1Gbps网络带宽的影响，青云的处理情况应当也是同理。（1024000*8*133=1089536000bps），腾讯云与青云传输带宽相仿，但连接处理速率相差比较明显。

阿里的多线程网络连接性能测试

同样，在阿里技术人员的肯定与支持下，至顶网也对阿里云32核64G云主机的多线程网络连接处理能力进行了测试：通过编写脚本起大量netperf -TCP_RR与netperf -TCP_CRR测试线程的方式，在200秒的测试时间内，对被测端进行测试。

同样为了方便进行统计，对网络连接性能的测试字节大小定在了1Byte，尝试着通过统计收、发端口的数据包传输速率，对TCP的连接建立速率进行统计。

通过收集被测端口数据包转发统计可以了解：在Netperf TCP_RR测试中，阿里云32核64G云主机网络连接处理能力达到了74万PPS以上的成绩。而在Netperf TCP_CRR测试中，连接处理能力有所下降，达到44万PPS的处理成绩。（注：这里统计的还是云主机虚拟网口的数据包转发，在连接建立时还会有建立连接的握手等数据包同样统计在其中，其实际处理能力有待今后采用更专业的测试工具或方法再进行验证。）

 netperf  TCP_RR

netperf  TCP_CRR

考虑到上面这种测试方案过于“激进”，为避免对其他公有云厂商虚拟网络造成过大影响，这个测试就没有在其它公有云上进行复测。希望今后有机会可以对更多公有云网络系统进行更全面的性能展示。

对于上面的应用测试结果，至顶网想表达的观点有两点：

1、对阿里云云主机的网络连接处理能力表示肯定。强大的网络连接处理能力，为网络应用传输提供了充分的计算能力保障。

2、现阶段给每个应用请求分配10Mbps的网络带宽，基本上可以保障常见网络应用的流畅运行。即便是减少到1Mbps带宽时，对于以图文为主的应用，用户也并非不可以接受。但是在每兆带宽上有10个以上的新建连接请求时，最好还是进行“报警”处理的比较好。无法及时处理的应用请求会迅速产生应用请求的堆积，对应用和网络系统产生无法预测的应用压力。