数字化转型方略 第14期 2019/11/15

测试:品质、品牌与价值的综合体现 ——2019至顶网公有云云主机评测综合分析报告(上)

文/至顶网云能力评估小组
在汲取去年测试经验后,今年将测试项目调整为针对网络、计算、存储及云主机可扩展能力这四个项目,被测试的还是去年测试过的AWS、Azure、UCloud、阿里云、百度云、华为云、金山云、京东云、青云、腾讯云这十个公有云厂商的云主机。各项测试分析结果如下:

前言:评测报告没人看?!(纯属牢骚,可以跳过)

在刚开始进行今年的公有云评测的时候,有人和我说,这种测试没有必要,没人会关注这个东西。果然是一句话点醒梦中人!忽然发现,现在评测报告少了,预测分析的报告多了。对于那些PPT厂商来讲,这样做很好理解,他们追求的本来就不是产品的销售利润,忽悠出一个概念,获取投资利润,至于研发的费用,自然是越少越好,像测试这种自揭其短的行为,自然是不存在的。可是还有很多确实是以产品、以技术为核心的企业也不对产品进行功能或性能的展示,这又是为什么呢?是作者太孤陋寡闻?作为一个专业媒体从业者,想必我的见识还不至于这么浅薄。

主观臆测一下,可能有两种原因:

一、多一事不如少一事。

作者曾经深入过许多企业参观或进行产品测试,给我的感觉是,研发的兄弟太确实不容易了,为了产品可以按时上线,别说996了,724的通宵都有可能,再多一个来挑毛病的,确实不招人待见,自然多一事不如少一事。

二、缺少专业测试工具

云计算的开源生态,可以说是一把双刃剑,它既降低了用户的使用门槛,又提升了参与者的进入门槛。免费固然可以得到使用者的青睐,但像测试软件这种专业而且小众的产品,免费是养不起身后成百上千的开发与维护人员的,收费的测试工具要想盈利,就只能走定制开发这种路,而缺乏了通用性,很难进行普适性的测试。因此现在对公有云测试就只能依靠一些Linux上的小工具来实现,但这样做的话,就出现了很多测试精度方面的问题,在下面的测试报告中会具体进行分析。

当然,作为媒体测试机构,我们也在积极和测试以及APM的厂商进行沟通与合作,相信随着企业对云上应用质量的关注,这类问题会尽快得到解决。

总体上讲,问题的根源还是在于厂商对测试的重视程度不够。对于未来的预期,谁都可以说,张口就可以讲。但测试是需要有实实在在的产品的。真心搞研发的厂商,也会有不自信的担忧,吹出去的牛,并不是谁都可以实现的。不搞研发的,更是乐得忽悠,声势做大一点,接盘侠总会有的,大不了上一下失信名单嘛。

但测试是一个对产品的品质、品牌和价值的综合性体现。在我以前写的文章里也说到过,中国制造需要升级为中国质造,才能树立好自身的品牌。这就需要勇敢的把自身产品展示出来,有比较,知不足,才能促进步。现如今,在制造方面,我们已经不弱于任何竞争对手,在创造方面,也正在迎面向前。因此在这里也希望更多有产品,有技术的厂商可以把自身的产品拿出来,通过公开评测的方式更好的向用户进行展示。这也是我们至顶网持续进行公有云主机产品测试的最主要目的。

最后还有一点需要提醒大家注意的是,对于测试结果,不能依靠简单的“比数”来评定产品的好坏,要结合测试环境和测试用例综合的进行分析。下面就是2019至顶网公有云主机评测综合分析报告正文。

网络、计算、存储及云主机可扩展能力的综合分析

2018年至顶网通过对公有云的测试和用户及专家调研后发现,那时公有云主机存在CPU处理性能低、内存占用高、云主机可扩展性问题突出之类的问题,并且发现虽然所有公有云主机都可以承受长时间网络业务访问,但对于目前问题高发的短时间大流量业务访问问题上未曾进宪涉猎。(具体测试报告可参见以下链接:http://www.zhiding.cn/special/CloudTest2018

因此在汲取去年测试经验后,今年特意将测试项目调整为针对网络、计算、存储及云主机可扩展能力这四个项目的评测之上,被测试的还是去年测试过的AWS、Azure、UCloud、阿里云、百度云、华为云、金山云、京东云、青云、腾讯云这十个公有云厂商的云主机,在本次测试中,依然选择的是适用于Web应用的2核4G公有云主机进行测试,测试系统盘大小为公有云厂商默认,公网带宽为5MB,操作系统为CentOS,Web服务为apache,为了更好模拟普通用户应用,在本次测试中,我们采用第三方开源建站工具WordPress完成测试网站搭建工作,并进行测试。云主机配置可参见不同公有云主机的单项测试内容。各项测试分析结果如下:

云主机Web应用、CPU占用测试结果分析

由于缺乏可以通用的网络应用性能测试仪表,在本次测试中只能征集热心用户在统一时间段对指定测试云主机IP进行Web应用访问的方式进行测试,并通过博睿数据应用性能监测工具,对请求发生次数、CPU、内存占用情况以及响应时间进行统计。由于用户行为并不可控,导致测试应用请求分配不平均现象出现,但是从本次测试所收集上来的测试结果来看,还是可以看出被测的公有云主机中所出现的问题。

Web应用请求次数与CPU占用统计图表

在Web应用请求次数与CPU占用统计图表中,蓝色柱状显示的是各个公有云主机最高每分钟内的应用请求次数,橘红色柱状显示的是公有云主机在测试时候最大CPU占用率。从中我们可以看出金山云的公有云主机虽然具有最多的每分钟Web应用请求次数,但是其CPU的占用也是最高,达到了99.02%,而每分钟请求次数与之相近的百度云,它的CPU占用率仅为13.82%。在本项测试中,华为云的CPU占用率最低,仅为5.86%,阿里云其次为6.05%,青云第三成绩为7.37%。国外的两个公有云CPU占用率均在15%以上,AWS CPU占用率为16.05%,Azure CPU占用率为15.19%。虽然AWS与Azure的Web应用请求次数分别达到了643次每分钟与500次每分钟,但明显低于百度云的684次每分钟,而百度云的CPU占用率虽然超过10%,但也未超出太高,只达到了13.82%

云主机平均响应时间、业务状态统计及广域网流量分析

平均响应时间

CPU占用率过高会对业务应用造成什么样的影响?我们通过云主机平均响应时间及业务状态统计可以进一步进行了解。以下统计数据依然是由博睿数据应用性能监测工具统计并得出。

平均响应时间对比图表

由于本次测试网络页面是利用第三方建站工具调取MySol数据库内信息生成,目前怀疑第三方建站工具数据调用存在效率问题导致所有公有云主机普遍存在最大响应时间过高现象(首次访问数据由硬盘加载到内存时的最大响应时间过长),为排除此不确定性因素,在结果对比时,取消了本次最大响应时间对比,只采用平均响应进行比较,测试结果可参见平均响应时间对比图表。

通过测试结果图表可以很明显的看出,金山云的平均响应时间呈现出的一军突起之势。平均响应时间高达521毫秒,这意味着绝大部分用户在点击在这台云服务器上的链接后,需要经过半秒钟的等待,才可以获取到点击的内容。而为了节省有限的公网带宽,我们本次测试设计的页面内只有一张低清晰度图片和一段文字而已,如果页面再相对复杂一些的话,用户体验将着实令人堪忧。

其它公有云中,以百度云和华为云的平均响应成绩最为出色,平均响应时间仅为19毫秒,阿里云仅以20毫秒的1毫秒之差位据其次。其它公有云的平均响应时间表现也都不错,除了UCloud、Azure与AWS之外,平均响应时间均在25毫秒左右。

在这里需要补充说明一下的是,平均响应时间不但与公有云主机的应用处理能力有关,还与公有云主机的广域网链路状态有很大关系,如果云主机厂商所能提供的广域网资源有限的话,也可能会对平均响应时间产生影响,换句话说,UCloud、Azure与AWS这三个公有云厂商在今后,可许更需要在广域网建设上多增加一些投入了。

业务状态统计

在业务状态统计对比中,首先要对博睿数据应用性能监测工具提出表扬,它可以根据每条访问连接的响应情况分为正常、较慢、很慢、停滞、错误,五种分别给予统计,可以让我们清晰的对业务状态进行统计,但要向博睿提出一个小小的建议,这么重要的功能最好可以做的更加醒目一些才好。

由于无法做到业务请求的平均分配,本次测试中至顶网云能力评估小组不在对正常业务请求进行统计,在业务状态统计中,只统计了十个被测公有云主机业务较慢、很慢、停滞、错误的情况,具体情况可参见业务状态统计图表。

业务状态统计图表

在业务状态统计图表中,我们可以清晰的了解到,由于受到CPU处理能力的拖累,金山云的公有云主机不但出现9次业务较慢、68次业务很慢的情况,还有178次业务停滞和4次错误现象出现。

在这项统计中,表现最好的是百度云,只有1次业务较慢情况出现,其次是阿里云和京东云,出现业务较慢和业务很慢情况各1次。其它公有云厂商除了Azure与UCloud之外,业务较慢与业务很慢情况各出现1到3次不等,具体情况可以参见每个公有云主机的独立报告,这里就不一一赘述了。至于Azure和UCloud在本项统计中分别出现了52次和47次的业务较慢情况,数字比较令人揪心,看来日后确实有必要多增加一些广域网带宽的投入了。

广域网流量

上面提到了有些公有云厂商需要增加些广域网带宽,然而带宽就是钱,现在有很多用户为了节省带宽费用的投入,也在采用按流量计费的方式对使用带宽进行付费。那么公有云主机业务应用时候的流量使用情况如何呢,至顶网云能力评估小组同样也进行了测试。

广域网最大流量统计表

由于流量分配的不均衡,必然会造成广域网流量的差异,因此我们将最大请求次数也同时列出来做一个参考。可是发现在最大流量中还是出现了不小的差异。最大流量最高的分别是百度云的4.0MB/s(注:博睿统计结果中确实是大写的B byte)、AWS的3.6MB/s与Azure的3.14MB/s,与其它公有云主机平均在1.X左右的最大流量存在着很大的差距。虽然他们三家的最高请求次数确实要多于其它公有云主机厂商,但是如果按比例进行换算的话比例又不对等,还是会出现很大差距。不知这个问题是统计数据造成的,还是由公有云主机造成的,看来今后还有必要针对这个问题进行更进一步的测试,仔细看一下,流量到底都去哪儿了。

内存占用

在去年公有云主机测试时,曾发现被测云主机普遍存在内存占用过高情况,今年同样对公有云主机系统内存占用情况进行了测试,下面内存数据同样是由博睿数据应用性能监测工具记录,最高是记录的在正常业务访问中最高内存占用结果,最低为访问结束后最低内存占用结果。具体数据参见内存占用图表。

内存占用图表

通过内存占用图表可以看出现阶段各公有云厂商公有云主机的内存占用情况均出现很大好转,除了金山云可能是因为在正常业务访问中出来过多等待和错误连接占用了过高的内存之外,其它公有云厂商的正常业务访问最高内存占用基本均在2.5G左右的水平线上下,而访问结束后内存恢复情况也都比较理想的保持在0.7G左右。由于结果相差不多,就不再逐一进行分析了。

公有云主机异常流量冲击下健康状况测试

以上都是针对正常业务来进行的测试,但是在业务应用中,从来不是一帆风顺,会有很多异常情况出现。于是接下来至顶网云能力评估小组就会人为的制造一些异常,来看一下在异常状态下这些公有云主机的健康状况如何。

为此,至顶网云能力评估小组采用在服务器端上用ab同时保持50个用户访问(ab参数-c 50)并建立1万连接和间隔数分钟后再发起同时保持50个用户访问并建立10万连接的方式,对公有云主机高并发应用处理能力进行测试。由于博睿数据的监测工具在云主机CPU跑满的情况下无法提供准确监控数据,因此选用Apache AB所提供的请求速率Requests/s结果进行统计。

Apache AB应用性能测试图表

在这里需要事先强调一件事情,Apache AB应用性能测试的数据,本身没有过多可以相互攀比的意义,此项测试是为了考验在CPU被业务处理打满之后云主机是否还可以正常运行。在上面测试中公有云主机正常业务应用中,每分钟处理300-500左右也就是每秒种处理5到10个业务应用,已经是单台云主机可以正常处理的极限了,当正常应用接近这个极限之前就需要考虑如何对云主机进行扩展,以保障业务的正常可持续运营。

上面的测试也可以充分说明这个问题,金山云的Apache AB 在1万次访问请求时,排名第二,在10万次访问请求时排名第一,但是在测试完成后,无论是远程管理的客户端还是公有云的控制台对其进行操作均无法进行响应,只有再通过控制台进行重启后,才能继续进行操作。也是本项测试中唯一一个没有经受住异常流量考验的公有云主机,其它公有云主机均成功的经受住了考验,可以在突发异常时稳定运行。

从上面的测试中我们可以了解,CPU的处理能力,与网络应用息息相关,虽然在正常应用流量测试中,绝大部分的公有云主机CPU使用并没有达到一个很高的数值,但这是因为为了测试所搭建的网页简单,没有过多互动性内容而导致的。公有云主机的CPU处理能力到底如何?为什么至顶网云能力评估小组一直提倡采用双核云主机?网络、计算、存储中云主机的系统盘存储能力又是如何?这些问题我们会在下半部分文章中再继续为大家进行解读。

本文章选自《数字化转型方略》杂志,阅读更多杂志内容,请扫描下方二维码

《数字化转型方略》杂志