差点错失整体跑分达到1062.7分的高性能云主机

简介:

7月20日左右,我接到一哥们儿的电话,邀请我参加他们研发的新一代高性能云主机的内部测试。这哥们儿多年前和我同一个公司做运维,后来被高薪挖去了某大型云计算企业,惹一帮人眼红,一年前辞了职,据说是加入了一个创业公司,立志要做新一代高性能云主机。

虽然,现在传统IT转云已经初露端倪,发展迅速,云计算替代传统IT是个大趋势。但是国内各家云,在圈子自嗨、TO-VC、玩概念热闹了几年后,终究没几个拿得出稳定可靠的产品。别看那么多云计算公司,找个靠谱的分布式快存储系统不容易,找个好用的云主机更不容易。我司算是个大型金融企业,也紧随趋势,有部分业务搬迁上云,经过一番对比选择的是现在市场占有率最高的某云,用下来感觉不功不过,稳定性和性能够用,价格也在可接受范围。

所以,对于这个测试邀请我虽然有所期待,期待主要是因为我这哥们儿做的东西一向靠谱,相信比格云这个所谓新一代高性能云主机不会太鸡肋,保留的是这个公有云平台也是基于KVM开发的,技术架构乍一看并无太多创新,而且功能点和架构基本也是现在市场上的云主机都有的基本功能,无太大亮点。我们公司的业务主要是金融类型的,大部分的数据是放在自己的服务器上,现在主要是把官网和部分数据库信息放在云上,希望云主机可以有较强的稳定度,当然,性价比也很重要。

7月28日是比格云正式开放内测,据说我是第一批邀请内测的用户。虽然心里犹疑,还是拿着哥们儿给的邀请码在比格云注册了,注册的时间是7月28日下午2点。比格云官网的整体风格应该是模仿国外网站走的简洁风,给人感觉还是比较小清新的。

我先进行了主机等资源的申请,这次给我们内测的云主机因为全免费,所以对可申请的资源做了一定限制。为了测试准确,我申请的资源如下:1台linux云主机,1个IP,10M带宽、CPU4核,内存16G,数据盘300G。

申请完进入控制台之后,整个页面呈现逻辑基本完整、简洁。但是发现有的地方过于简单,比如个人账户下针对申请主机和带宽等的操作页面,信息较少,专业性打了一定折扣。可能因为刚开始内测,整个网站的深度感觉还有待加强。

整体操作的便捷度也不错,包括申请云主机,重启/开关机,修改密码等功能响应迅速,但是个别需要等待的操作缺少了邮件或短信等提示,比如申请了云主机关闭网页后,就无法知道主机的申请状态了。这些应该在比格云后期的运营中会加以完善。

接下来是性能测试,这也是让我颇感意外的测试结果,整体服务器性能相当不错,包括磁盘IO、网络传输等性能都相当优秀,尤其是整体跑分达到了1062.7分,大大超出我的预期。

具体测试内容如下:

一、云主机性能测试:磁盘IO读写速度、SSD硬盘速度测试

首先我用“dd if=/dev/zero of=test bs=64k count=4k oflag=dsync”和“dd if=/dev/zero of=test bs=8k count=256k conv=fdatasync”测试了主机的磁盘写入性能和顺序读性能。conv=fdatasync与oflag=dsync的区别在于,sync函数只是将所有修改过的块缓冲区排入写队列,然后就返回,它并不等待实际写磁盘操作结束。而fsync函数只对由文件描述符filedes指定的单一文件起作用,并且等待写磁盘操作结束,然后返回。

测试出来的结果如下:

dd if=/dev/zero of=test bs=64k count=4k oflag=dsync

268435456字节(268 MB)已复制,3.04623 秒,88.1 MB/秒

dd if=/dev/zero of=test bs=8k count=256k conv=fdatasync

2147483648字节(2.1 GB)已复制,4.66915 秒,460 MB/秒

在SSD性能测试方面,我用hdparm命令测试出来的结果如下:

hdparm -t /dev/vda

/dev/vda:

Timing buffered disk reads: 2738 MB in 3.00 seconds = 912.60 MB/sec

测试到这里不得不承认比格云在性能方面的确是超越了不少同行,令人惊喜。

二、云主机网络传输速度测试:

接下来是网络速度的测试,我用speedtest_cli命令检测了网络实时速度。测试结果如下:(原谅我不喜欢截图)

python speedtest_cli.py --share

Retrieving speedtest.net configuration...

Retrieving speedtest.net server list...

Testing from CNNIC (211.147.80.209)...

Selecting best server based on latency...

Hosted by Shanghai Branch, China Unicom (Shanghai) [19.64 km]: 2.965 ms

Testing download speed........................................

Download: 191.33 Mbit/s

Testing upload speed..................................................

Upload: 11.17 Mbit/s

Share results: http://www.speedtest.net/result/5569136010.png

三、云主机性能综合测试:UnixBench跑分工具测试

最后是整体跑分,是用了一段时间主机之后,用UnixBench跑的,UnixBench是一款开源的测试 Unix 系统基本性能的工具,是比较通用的测试性能的工具,可以对云主机的系统调用、读写、进程、图形化测试、2D、3D、管道、运算、C库等系统基准性能提供测试数据。另外,UnixBench版本不同也去导致测试得分的结果有很大的差别,大家如果要使用UnixBench来测试VPS的性能的话,最好是使用同一个版本的UnixBench。

跑分结果如下:

BYTE UNIX Benchmarks (Version 4.1-wht.2)

System -- Linux 10-100-10-104 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

/dev/vda1 62897156 1962772 60934384 4% /

Start Benchmark Run: 2016年 08月 21日 星期日 23:50:41 CST

23:50:41 up 24 days, 13:35, 2 users, load average: 0.02, 0.07, 0.06

End Benchmark Run: 2016年 08月 22日 星期一 00:00:44 CST

00:00:44 up 24 days, 13:45, 2 users, load average: 13.20, 5.51, 2.45

INDEX VALUES

TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 376783.7 51385251.7 1363.8

Double-Precision Whetstone 83.1 2226.1 267.9

Execl Throughput 188.3 12232.3 649.6

File Copy 1024 bufsize 2000 maxblocks 2672.0 1046805.0 3917.7

File Copy 256 bufsize 500 maxblocks 1077.0 282805.0 2625.9

File Read 4096 bufsize 8000 maxblocks 15382.0 5193950.0 3376.6

Pipe-based Context Switching 15448.6 1357258.8 878.6

Pipe Throughput 111814.6 6551144.9 585.9

Process Creation 569.3 46436.2 815.7

Shell Scripts (8 concurrent) 44.8 2859.0 638.2

System Call Overhead 114433.5 10112701.4 883.7

=========

FINAL SCORE 1062.7

以上是我的测试结果,从测试结果来看,比格云的各项性能数据还是非常有竞争力的,看来现在IAAS市场各项架构技术的发展实在是迅猛,我们这些所谓的老鸟也要加快学习的步伐。而作为拖延症患者,选择在这个时候把这篇测试报告写出来,是因为比格云在内测结束,又经历了两个月的闭关优化后,即将正式推出这个新一代高性能云主机,作为比格云第一批内测用户代表,在这里祝愿比格云能够大卖,用心的好产品值得被市场关注。

另外,顺便提醒下各位在测试云主机的时候,为了能够得到更为准确和详细的相关性能测试数据,我们应该多角度、全方位地运行多种测试工具来进行检测,同时也要记得排除因本地网络环境而造成的数据结果的错误。


本文作者:佚名

来源:51CTO

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
4月前
|
消息中间件 缓存 监控
阿里P8整理的《百亿级并发系统设计》实战教程,实在是太香了
说实话,如果面试官问你这个题目,那么你必须要使出全身吃奶劲了。为啥?因为你没看到现在很多公司招聘的 JD 里都是说啥有高并发经验者优先。
|
12月前
|
消息中间件 运维 JavaScript
在公司混的差,不一定是能力不行,可能和组织架构有关!
在公司混的差,不一定是能力不行,可能和组织架构有关!
|
缓存 监控 前端开发
项目维护几年了,为啥还这么卡?
前段时间有个客户问我,为啥你们项目都搞了好几年了,为啥线上还会经常反馈卡顿,呃呃呃。。
|
存储 SQL 缓存
如何设计一个支持一亿用户的系统,心中有方案遇事不慌!
如何设计一个支持一亿用户的系统,心中有方案遇事不慌!
155 0
如何设计一个支持一亿用户的系统,心中有方案遇事不慌!
1032 挖掘机技术哪家强 (20 分)
为了用事实说明挖掘机技术到底哪家强,PAT 组织了一场挖掘机技能大赛。现请你根据比赛结果统计出技术最强的那个学校。
89 0
|
移动开发 前端开发 小程序
不愧是前端老油条,分分钟看出我方案的bug
国庆前刚开发完一个小需求,常规性的做了一次code review,不过这次review有所不同,我们组前端老油条竟然参会了,平时发会邀都不来的。 不过不愧是老油条,竟然分分中发现了问题,老油条的地位又在我们小前端的心里巩固了一下。 和往常一样,review前先过一遍技术方案,一让大家快速的了解需求,二来分析下技术方案是否存在问题,是否合理,一般情况下,技术方案没问题,后面的代码review感觉就没啥必要了,因为很少有人听。
111 0
不愧是前端老油条,分分钟看出我方案的bug
|
SQL 缓存 安全
如何做好大促时的系统高可用
面对大促不确定的流量,我们需要做好全方位的流量控制与防护能力,确保我们的系统始终工作在预期的范围之内。首先我们需要有流量的实时监控以及水位诊断分析能力,确保我们知道当前系统所处的一个状态;在业务的链路入口,我们需要做好链路入口的容量评估以及峰值流量的限流配置、同时需要开启热点隔离能力,防止黑马商品、黑产刷单等不确定因素造成的稳定性影响;在微服务内部我们需要配置单机流控,针对微服务内部异步的流量我们可以配置流量平滑能力做到削峰填谷的效果;针对下游依赖的服务以及组件(数据库、缓存等),我们可以通过慢SQL发现以及熔断、慢调用隔离、热点探测等手段保障稳定性。
如何做好大促时的系统高可用
|
存储 编译器
数据存储(跑路人学习笔记)
数据存储(跑路人学习笔记)
数据存储(跑路人学习笔记)
L1-5 VV的烦恼 (15 分)
VV今天去图书馆学习,发现电脑没充满电,电量只剩下n,而她有m1个低计算量程序需要运行,m2个高计算量程序需要运行 现假设电脑在运行低计算量程序的情况下消耗电量p1每分钟,运行高计算量程序的情况下消耗电量p2每分钟,运行不同程序之间没有时间间隔。 请问VV能把所有程序运行完吗?
102 0