标签归档:阿里云

阿里云, ucloud, 青云 mysql 性能 简单测试

这三家我都有使用

先说 使用感受

  • 青云最专业,后台控制面板也好用。关机只收部分费用也非常适合做测试机器
  • 阿里云没什么要说的,很均衡。不折腾就上阿里云。 就是有几次无故重启不通知
  • ucloud 问题很多,比如 购买的 IP 无法访问 mailgun, 创建主机失败,只能删了重新创建。 网络突然故障, github 无法 clone

这几天有想法 测一下 这三家提供的 mysql 读写性能如何, 于是写了下面的脚本。
先说一下这三家 mysql 的配置:

  • 青云是最低一档的 1 核 2G mysql5.5 , 配置默认
  • ucloud 是最低一档 600M 内存, mysql5.6 标准版,默认配置
  • 阿里云是 第二档 600M 内存, mysql5.5 ,默认配置

所以这是一个不严谨的测试,因为这些机器都是早就买好的。所以无法做到测试环境一模一样。

测试结果:

每家各测试多次,结果比较稳定,就选取其中的一次结果:

青云

INSERT ONE 3.25666999817
INSERT MANY 0.217604875565
QUERY 3.51868581772

ucloud

INSERT ONE 5.17626905441
INSERT MANY 1.33850288391
QUERY 2.40842795372

阿里云

INSERT ONE 5.36786603928
INSERT MANY 0.239859104156
QUERY 5.58612704277

测试脚本:

# -*- coding: utf-8 -*- import os import time import random import base64 import MySQLdb MYSQL_HOST = '127.0.0.1' MYSQL_PORT = 3306 MYSQL_USER = 'root' MYSQL_PASSWORD = 'root' MYSQL_DB = 'bench_test' max_num = 10000 conn = MySQLdb.connect( host=MYSQL_HOST, port=MYSQL_PORT, db=MYSQL_DB, user=MYSQL_USER, passwd=MYSQL_PASSWORD ) # 数据库需要提前建立好,但是表不用 cursor = conn.cursor() sql = """create table if not exists test ( id integer not null primary key, age integer not null, name varchar(255) not null )""" cursor.execute(sql) conn.commit() cursor.close() # 生成测试数据 DATA = [] for i in range(max_num): DATA.append((i+1, i+1, base64.b64encode(os.urandom(64)))) def insert_one_test(): cursor = conn.cursor() cursor.execute("delete from test") start = time.time() for value in DATA: cursor.execute('insert into test (id, age, name) values (%s, %s, %s)', value) conn.commit() cursor.close() print "INSERT ONE", time.time() - start def insert_many_test(): cursor = conn.cursor() cursor.execute("delete from test") start = time.time() start_index = 0 batch_amount = 2000 while start_index < max_num: values = DATA[start_index: start_index+batch_amount] cursor.executemany("insert into test (id, age, name) values (%s, %s, %s)", values) start_index += batch_amount conn.commit() cursor.close() print "INSERT MANY", time.time() - start def query_test(): cursor = conn.cursor() start = time.time() for i in range(10000 * 1): _id = random.randint(1, max_num) cursor.execute("select id, age, name from test where id = %s", (_id,)) result = cursor.fetchone() assert result[1] == _id print "QUERY", time.time() - start if __name__ == '__main__': insert_one_test() insert_many_test() query_test() 

https://cn.v2ex.com/t/233000

CDN已成云商必争之地 看CDN年整体收入增速800%的阿里云如何放大招?

近日,阿里云PR一改往日规模会议的模式,落脚创业大街,在3W咖啡办起了CDN专项技术媒体分享会。据笔者观察,这是阿里云2016年PR思路的一大改观,与同为BAT级的腾讯云一同走起了小清新路线。从邀请函中明显看出,本场媒体沙龙的主题剑指传统CDN,“传统CDN会更好?”的疑问在本次技术分享中被揭晓。

传统CDN闷声挣大钱的时代已去

随着用户应用需求类型的改变,CDN作为网络的一部分,已经成为企业级市场追捧的焦点之一。因为通过CDN可以更多的把计算和存储推向边缘,实实在在的让用户感受到最真实的体验。所以,当云计算大规模落地,云化CDN越来越受到用户的青睐。

我们知道,传统CDN一直以来,盘踞在产业链条的一端,悄默声的挣去高额利润。但在阿里云首席科学家章文嵩的眼里,这种传统CDN闷声发大财的局面,很快或者已经被打破。“云化CDN会完全重新将CDN定义。”因为随着创新技术的发展,用户应用习惯的更改。更多的应用场景会更多的被推到边缘节点上,不光是云上的计算,也可能变成边缘计算。“CDN可以说是云的入口,对于任何的云厂商来说CDN都很重要,而且CDN一定是云计算厂商的必争之地。” 章文嵩表示。

为什么肯定?原因很简单,可以被主要归纳为两点。第一,云时代里,企业级需求在改变。用户不在单一将CDN当做一个固定资源来所取,而是在其中加入更多计算、存储、网络、安全等多方面需求,而传统CDN厂商并不具备这样的综合技术实力,所以云服务商就有了更大的机会;第二,池化资源是云计算的本质属性,CDN一旦池化,将会带来更多的规模与价格优势,而这也是传统CDN能力达不到的。据介绍,像云厂商或者国内的BAT级别的互联网公司,他们在基础设施规模的建设上都比传统的CDN厂商大得多。整体的规模效应会带来成本下降,从而会带来更低的价格。

CDN的C从内容(Content)到云(Cloud)的改变

“未来三五年,随着云厂商的进入,整个CDN产业的格局将会发生翻天覆地的变化。” 章文嵩预测。

CDN原来的单词是Content Delivery Network,侧重整体应用的内容分发。而随着云厂商在产业内的介入,大部分企业用户的应用构建、传输都将在云上进行,所以CDN的内涵也将逐步转变为Cloud Delivery Network,云上网络分发的印记将更加深入。

“随着用户需求的适时而变,CDN技术的发展将会融合更多的创新思维和前瞻性的理念进去,云厂商凭借自身的综合实力优势,发展会越来越快。未来两到三年,传统CDN服务商光环不在,有可能整个CDN的行业江湖就会易主。” 章文嵩表示。

对此,阿里云CDN事业部总监朱照远用实际案例带来例证。分享当天,他举了阿里云与芒果TV合作打造风靡全球“超级女声”APP的例子。芒果TV对阿里云提出了苛刻的CDN需求:两周打造一个原型出来!其中APP要实现包括视频的海选、直播与终极PK的功能,其中技术实现要能提供视频的转码、网络专用通道、数据库、消息中间件等等十几种的能力。“这对传统CDN是不可能做到的,因为他们解决不了用户的所有痛点,或需求的功能点。传统的CDN只能提供单一的CDN组件,但是客户需要的却是计算、存储、分发、大数据、安全等等系列解决方案。”

所以,传统CDN在面临复杂的业务场景以及复杂的客户需求时,会表现出能力不足,束手无策。在云时代里,单一的内容分发,已经不能满足用户的多样化需求,云化CDN将给用户带来全新选择。

CDN6.0版本有哪些绝杀技?

阿里云CDN发源于淘宝自有CDN,并于2014年3月开始正式对外为提供服务。在商业化服务2周年之际,阿里云发布了经过10年淘宝历练,5次更新迭代的CDN6.0版本。

据介绍,此次发布的极速CDN 6.0版本,除了首次在业界提出Cloud Delivery Network(云分发网络)理念外。还融合了云计算、大数据技术,涵盖视频和移动两个解决方案以及大数据分析、HTTPS加速等新功能,可以为客户提供一站式的云CDN解决方案。

具体说来,6.0版本针对视频类应用推出视频云解决方案,提供一站式视频点播、直播服务,集内容采集、上传加速、存储、码转/截图、鉴黄服务、CDN分发及播放器等功能于一体,极大地优化了客户体验。据测算,视频云端到端时延仅2秒,流畅度95%,在同等清晰度下,码率低30%,这意味着客户可以节省30%的成本。

另外,新版CDN还提供了HTTPS加密功能,可以让客户内容防劫持、防篡改、防窃密,保证通信的安全。

大数据工具也是6.0版本的重要特色。阿里云将打通CDN和“数加”平台的大数据计算产品MaxCompute,客户如果需要,可以一键上传自己的日志数据,使用强大的MaxCompute进行精细化分析数据,让数据产生商业价值。



▲阿里云CDN用户展示

据透漏,移动端的CDN整体解决方案也即将上线,移动加速可提升40%性能,并具备HTTPDNS功能,具有防域名劫持、调度精确、稳定可靠等特点。

2015年阿里云CDN客户数已突破10万,客户规模是传统CDN厂商客户之和的20倍,在整个CDN市场稳居行业第一。业务营收同比增长800%,增长率也比传统CDN厂商的增速快了约20倍。“这一年越来越多的大中型企业级CDN客户采用CDN和云计算证明了我们对于行业前景的判断。企业在使用公共云架构的同时选择了云CDN,其综合竞争优势显著,这与传统IT架构向云计算转变的历史趋势一致。” 朱照远表示。

▲国内500+节点,超过10T带宽,单节点40-300G,海外覆盖6大洲(图示是阿里云CDN有部署节点的国家或地区)

top3云服务器磁盘IO性能对比测试(阿里云、腾讯云、ucloud)–结果阿里云就是一坨屎

top3云服务器磁盘IO性能对比测试,测试对象包括阿里云、腾讯云、ucloud,测试磁盘包括系统盘,云盘(其中阿里云包括高速云盘),结果腾讯云本地硬盘最快达到600MB/s,因服务器没有云盘但官网说明有60MB/s,Ucloud磁盘读达到400多MB/s,阿里云垃圾仅有50MB/s,只能说阿里云真的很坑爹!很坑爹!!很坑爹!!

1)腾讯云服务器系统盘(641.98 MB/sec)及云盘( 627.78 MB/sec)IO读性能测试

[root@~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       7.9G  3.5G  4.0G  47% /
/dev/vdb        197G  5.3G  182G   3% /home
[root@ ~]# hdparm -Tt /dev/vda1 

/dev/vda1:
 Timing cached reads:   20212 MB in  2.00 seconds = 10122.68 MB/sec
 Timing buffered disk reads: 1926 MB in  3.00 seconds = 641.98 MB/sec
[root@~]# hdparm -Tt /dev/vdb 

/dev/vdb:
 Timing cached reads:   19774 MB in  2.00 seconds = 9903.22 MB/sec
 Timing buffered disk reads: 1884 MB in  3.00 seconds = 627.78 MB/sec

腾讯云硬盘与本地硬盘的对比

云硬盘 本地硬盘
约0.30元/GB月。 约0.30元/GB月。
可靠性更高:数据冗余存储,且分布在多台服务器。 数据冗余存储,分布在本服务器。
容量更大:最大支持4TB的数据盘。 最大支持500GB。
性能:顺序读写约60MBPS。 性能更高:顺序读写超过200MBPS。
选购云硬盘的服务器支持升级CPU,内存,硬盘容量及带宽升级。   选购本地盘的服务器不支持配置升级,仅支持带宽的升级。

详细参考:https://buy.cloud.tencent.com/price/cbs

2)ucloud系统盘(513.27 MB/sec)及云盘(256.60 MB/sec)IO读性能测试

[root@ ~]# hdparm -Tt /dev/vda1^C
[root@ ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/vda1       20641404 4259668  15333212  22% /
/dev/vdb        20642428 3620124  15973728  19% /data
[root@10-10-133-43 ~]# hdparm -Tt /dev/vda1

/dev/vda1:
 Timing cached reads:   14662 MB in  2.00 seconds = 7337.32 MB/sec
 Timing buffered disk reads: 1540 MB in  3.00 seconds = 513.27 MB/sec
[root@ ~]# hdparm -Tt /dev/vdb

/dev/vdb:
 Timing cached reads:   14728 MB in  2.00 seconds = 7370.36 MB/sec
 Timing buffered disk reads: 770 MB in  3.00 seconds = 256.60 MB/sec

Ucloud的Udisk没有公布磁盘详细IO情况:https://docs.ucloud.cn/storage_cdn/udisk/price.html

3)阿里云系统盘(51.57 MB/sec)、普通云盘(65.63 MB/sec)、高速云盘(57.05 MB/sec)IO读性能测试,SSD云盘99.78 MB/sec

[root@~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       40G  6.0G   32G  16% /
/dev/xvdc        99G   48G   46G  52% /home/mysql
/dev/xvdb       985G  317G  618G  34% /data

[root@~]# hdparm -Tt /dev/xvda1

/dev/xvda1:
 Timing cached reads:   14908 MB in  2.00 seconds = 7462.28 MB/sec
 Timing buffered disk reads: 156 MB in  3.03 seconds =  51.57 MB/sec
[root@iZ94fp4872nZ ~]# hdparm -Tt /dev/xvdb

/dev/xvdb:
 Timing cached reads:   14866 MB in  2.00 seconds = 7440.43 MB/sec
 Timing buffered disk reads: 198 MB in  3.02 seconds =  65.63 MB/sec


[root@]# hdparm -Tt /dev/xvdc

/dev/xvdc:
 Timing cached reads:   15070 MB in  2.00 seconds = 7541.93 MB/sec
 Timing buffered disk reads: 172 MB in  3.01 seconds =  57.05 MB/sec

阿里云盘SSD测试

# hdparm -Tt /dev/vda1

/dev/vda1:
 Timing cached reads:   16966 MB in  2.00 seconds = 8496.07 MB/sec
 Timing buffered disk reads: 300 MB in  3.01 seconds =  99.78 MB/sec

阿里云磁盘、SSD盘、搞笑云盘、普通云盘、本地SSD硬盘对比

块存储 SSD云盘 高效云盘 普通云盘 本地SSD盘
最大容量 2048 GB 2048 GB 2000 GB 800 GB
最大 IOPS 20000 3000 数百 12000
最大吞吐量 256 MBps 80 MBps 20 – 40 MBps 250 – 300 MBps
性能计算公式 IOPS=min{30*容量,20000}

吞吐量=min{50+0.5*容量,256}MBps
IOPS=min{1000+6*容量,3000}

吞吐量=min{50+0.1*容量,80}MBps
不适用 不适用
访问时延 0.5 – 2 ms 1 – 3 ms 5 – 10 ms 0.5 – 2 ms
数据可靠性 99.9999999% 99.9999999% 99.9999999% 仅物理机可靠性、无SLA保证
API名称 cloud_ssd cloud_efficiency cloud ephemeral_ssd
价格* 1.0元/GB/月 0.5元/GB/月 0.3元/GB/月 0.8元/GB/月
典型应用场景
  • I/O密集型应用
  • 中大型关系数据库
  • NoSQL数据库
  • 中小型数据库
  • 大型开发测试
  • Web服务器日志
不被经常访问或者低I/O负载的应用场景

Hadoop、NoSQL等分布式应用,应用本身有极高的可靠性,需要低时延、高I/O的存储。

供大家对云服务器的数据参考,2017.10.09增加普通电脑及服务器IO读写性能测试

1)DELL 1U PowerEdge R410服务器,RAID1 SAS 300G硬盘,测试比阿里云SSD云盘还要快。

# hdparm -Tt /dev/sda3

/dev/sda3:
 Timing cached reads:   11298 MB in  2.00 seconds = 5656.25 MB/sec
 Timing buffered disk reads:  442 MB in  3.01 seconds = 146.85 MB/sec

2)普通家庭电脑 希捷1T盘

# hdparm -Tt /dev/sda1

/dev/sda1:
 Timing cached reads:   19500 MB in  2.00 seconds = 9760.70 MB/sec
 Timing buffered disk reads: 436 MB in  3.01 seconds = 144.87 MB/sec

3)普通家庭电脑 西数4T盘

# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   24872 MB in  2.00 seconds = 12455.68 MB/sec
 Timing buffered disk reads: 464 MB in  3.01 seconds = 154.13 MB/sec

阿里CDN价格总览及计费停服规则,最便宜5Gbps起峰值带宽计费2.28万/G/月

阿里CDN价格总览及计费停服规则:1、按[流量]计费说明,根据流量阶梯大于100TB,0.26元/GB;2、按[峰值带宽]计费说明,根据峰值带宽阶梯最便宜算0.76元/Mbps/日=2.28万/G/月。

  • 计费项:下行流量
流量阶梯 新价格(元/GB)
0GB-10TB(含) 0.36
10TB-50TB(含) 0.32
50TB-100TB(含) 0.30
大于100TB 0.26

注: 为防止异常的恶意流量给用户造成损失,按流量付费方式,默认带宽上限为10Gbps

  • 计费规则

    1. 计费项:流量
    2. 付费方式:后付费
    3. 计费规则:按流量阶梯价格计费,当月超额累进(以自然月为一个累计周期)
    4. 计费周期:按小时计费,实时扣费(每小时出账单并扣费)
  • 流量账单收费示例

    5月1日0:00至5月15日8:00累计消耗的流量为10200GB,5月15日8:00至5月15日9:00消耗的流量为90GB(注:10TB = 10240GB),则5月15日8:00到9:00产生账单金额为40GBx0.36元/GB+50GBx0.32元/GB=30.40元 (即从10200GB起算,40G在0GB – 10TB阶梯内,单价为0.36元/GB;50G在10TB – 50TB阶梯内,单价为0.32元/GB)

说明:

账单出账时间为当前计费周期结束。账单出账时间通常在当前计费周期结束后一小时内, 例10:00-11:00的账单会在11:00以后生成, 具体以系统出账时间为准,账单生成后会自动从您的账户余额中扣除费用以结算账单。

  • 计费项:峰值带宽
峰值带宽阶梯 价格(元/Mbps/日)
0-512Mbps 1.00
512Mbps-5Gbps 0.90
大于5Gbps 0.76

注: 按宽峰值计费是以您CDN服务产生的带宽最高值(单位Mbps)为结算标准.

注: 按峰值带宽方式,默认带宽上限支持100Gbps,需要更大的用量,请联系我们.

  • 计费规则

    计费项:峰值带宽

    1. 付费方式:后付费
    2. 计费规则:按峰值带宽阶梯价格计费,当日超额累进(以自然日为一个累计周期)
    3. 计费周期:按日计费,实时扣费(每日零点后出前一日账单并扣费,具体出账时间以系统为准)。
  • 按峰值带宽账单收费示例

    用户当日的峰值带宽为912Mbps,则用户的账单费用应为512×1.0元+400×0.9元=872元(小于512Mbps单价为1.0元,大于512Mbps小于5Gpbs单价为0.9元)

说明:

  • 账单出账时间为当前计费周期结束(自然日)。账单出账时间通常在当前计费周期结束后一小时内, 6月17日的账单会在6月18日零点以后生成, 具体以系统出账时间为准,账单生成后会自动从您的账户余额中扣除费用以结算账单。
  • 按宽峰值带宽计费是以您CDN服务产生的带宽最高值(单位Mbps)为结算标准

系统以5分钟为时间粒度,采集CDN全网节点的域名汇总数据,一天采集288个点,做为计费依据。

  1. 当您未付清CDN服务产生的账单,则服务处于欠费状态。
  2. 服务欠费后延时24小时停服,在欠费后24小时内会以短信/邮件的方式提醒用户尽快支付账单,在欠费后24小时内进行充值,您的服务将不会受到停服影响;
  3. 如您未在欠费后24小时内未能及时充值。CDN服务将停止服务;停止服务后,CDN也将停止计费。您所占用的Cache资源将被释放,配置信息保留12个月。
  1. 按流量计费:系统根据CDN服务最近7小时的账单应付金额平均值来判断用户账户余额是否足以支付其CDN服务下3个账期的费用,如果不足以支付将给予短信/邮件提醒;
  2. 按峰值带宽计费:系统根据CDN服务最近前一个计费周期(天)的账单应付金额值来判断用户账户余额是否足以支付其CDN服务下一个计费周期(天)的费用,如果不足以支付将给予短信/邮件提醒;
  3. 如果您开启了余额预警(控制台中>账户管理>余额预警开关),当账户余额小于用户设定的预警值时将给予您短信/邮件提醒。

在控制台上看到的流量,是我们应用层日志统计出的流量,但是实际产生的网络流量却要比应用层统计到的流量要高出7%-15%;这个主要的原因有两个:

1、TCP/IP包头的消耗:众所周知,我们的HTTP请求是基于TCP/IP协议的,现有的互联网中,每个包的大小最大是1500个字节,而这1500个字节 中,就包含了TCP和IP协议插进来的40个字节的包头,包头部分,也会产生流量,但是,这个加包头的动作是由内核层 的协议栈完成的,无法被应用层统计到,日志里也就不会记这40个字节的流量了,这部分的流量,会占到我们通过日志 计算出流量的2.74%(40/1460)以上,正常情况下,会占到3%左右。

2、TCP重传:根据互联网物理网络的负载情况,正常情况下,我们所发送的包会有3-10%左右会被互联网丢弃掉,被丢弃掉之后,服 务器会对丢弃的部分进行重传,重传动作是由内核层协议栈处理的,应用层也无法统计到,这部分流量占我们日志计算 出流量的比例,根据网络的好坏而不等,在凌晨,互联网轻载的情况下,重传率会较低;在晚高峰,互联网重载的时候 ,重传会上升,一般情况下,在3%-7%之间。

因此在业界标准中,会在原有流量的基础上再加上7%-15%的网络消耗做为计费流量统计,我们取最小值7%做为网络消耗统计。

  • 由于LocalDNS服务器有缓存,停用CDN服务后,若缓存未过期,LocalDNS还会把针对已停用CDN域名的请求直接打到CDN节点,造成少量CDN流量计费。
  • 一些下载类软件也存在LocalDNS缓存,在这部分缓存过期前,已停用的CDN还会造成少量的CDN节点流量计费