云计算之路:SSD云盘+ECS(I/O优化)

阿里云推出SSD云盘+I/O优化的ECS有一段时间了,这个功能优化是为了解决用户量大、高并发读写等问题。据阿里云官网介绍,SSD云盘最高提供20000随机读写IOPS、256MB/S吞吐量的存储性能。I/O的优化为ECS实例与SSD云盘直接提供了更好的网络能力。近期有幸拿到了这款产品的公测机会,那么下面就开启一段测试使用之旅吧。

首先在订购页面中选择自己所需的配置,由于我是测试体验就一切按照最低配置来进行购买,如下图。

创建成功之后就可以使用ECS了,通过Google了解到AnvilPro是用来测试SSD硬盘常用的软件,那我就用这款工具来对阿里云的SSD云盘进行测试。在测试之前,有必要解释一下为什么阿里云会十分看重这次功能优化。

众所周知,磁盘I/O性能一直是阿里云备受诟病的地方。I/O 不仅会影响高并发时服务器的响应速度,更会对数据库性能的发挥产生巨大影响。所以阿里云之前推出了一款产品——RDS(Relational Database Service)来解决这个问题。这个产品是将直接运行于物理服务器上的数据库实例租给用户,通过对硬件资源的独占分配避开云服务器硬盘IO共享带来的性能问题。就如我们之前系列文章所说的RDS是止痛药,不是解药

在服务器上打开AnvilPro软件,分别以C盘1G、E盘4G、E盘16G为测试,得到如下图的测试数据。

这款软件读取部分分为Seq 4MB(连续读取)、4K(随意读取,并发1个队列)、4K QD4(随意读取,并发4个队列)、4K QD16(随意读取,并发16个队列)、32K、128K;写入部分为Seq 4MB、4K、4K QD4(随意读取,并发4个队列)、4K QD16(随意读取,并发16个队列)。从图中可以看出IOPS与MB/S可以直接进行换算,比如以C盘1G的测试标本,4K读取是1201.75,即每秒可以读取1201个4K文件,即1201*4K/1024 = 4.69MB/S。

通过上面三张图得出的分数分别为247.19、201.70、157.72,不知道这些分数处于什么水平。如果对这方面有经验的童鞋或者测试过同等配置的童鞋给些意见。

接下来我在阿里云官方论坛里找到他们对这个产品的描述,对SSD云盘和本地SSD盘,普通云盘做了一下比较,如下图:

然后SSD云盘适合的业务场景:

通过上面的介绍,对SSD云盘以及其所应用的场景有了大致了解了。总体来说如果你的网站对高并发读写、用户访问量大、实时连接数要求很高的话,不妨尝试一下SSD云盘。

时间: 2024-10-07 05:06:30

云计算之路:SSD云盘+ECS(I/O优化)的相关文章

云计算之路:测试阿里云SSD云盘+ECS(I/O优化)

阿里云推出SSD云盘+I/O优化的ECS有一段时间了,这个功能优化是为了解决用户量大.高并发读写等问题.据阿里云官网介绍,SSD云盘最高提供20000随机读写IOPS.256MB/S吞吐量的存储性能.与普通的ECS实例相比,IO优化后的ECS,为ECS实例与SSD云盘直接提供了更好的网络能力.近期有幸拿到了这款产品的公测机会,那么下面就开启一段测试使用之旅吧. 首先在订购页面中选择自己所需的配置,由于我是测试体验就一切按照最低配置来进行购买,如下图. 创建成功之后就可以使用ECS了,通过Goog

【免费公测】阿里云SSD云盘,不仅仅是IO提速10倍

今天很高兴为大家介绍最新的ECS存储服务:SSD云盘. SSD云盘基于全SSD存储介质.利用阿里云飞天分布式存储技术,提供数据可靠性99.999%的高性能存储:该产品具备以下特点: l  高性能:单个SSD云盘最高提供10000随机读写IOPS.160MB/s吞吐量的存储性能: l  高可靠性:SSD云盘采用分布式三副本机制,提供99.999%的数据可靠性: l  每GB提供30 IOPS:每GB容量提供30个随机IOPS能力,最大提供10000随机读写IOPS性能:比如100GB的SSD云盘,

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会