「快速评测」——最新云主机测试工具大盘点 (云主机测试工具)

随着云计算技术的发展,越来越多的企业开始将自己的业务转移到云端,并选择了各种不同的云主机来承载它们的业务。然而,如何评估和选择最适合自己的云主机成为了各个企业亟需解决的问题。这时,一个好的云主机测试工具就显得尤为重要了。本文将详细介绍最新的云主机测试工具,以期为大家解决这个问题。

一、测试工具的分类

1. 基准测试工具

基准测试工具是用来测试系统性能的工具,如 CPU、内存、IO、网络等方面的性能测试工具。比如 UnixBench、SysBench、Iozone 等。

2. 专项测试工具

专项测试工具则是针对某一方面特定需求的测试工具,例如:网络BP(网络吞吐测试)、FIO(磁盘性能测评)、ApacheBenchmark(Web 压力测试)等。

二、最新测试工具介绍

1. UnixBench

UnixBench 可以测试出系统的整体性能,包括 CPU、内存、IO、网络等方面,是属于基准测试工具的一种。该工具能够自动测试出如下信息:CPU 相关信息,CPU 浮点执行速度,CPU 整型执行速度,系统内存带宽,磁盘 IO 性能等。使用这些信息就可以评估出系统的整体性能。可以使用 UnixBench 在云主机、VPS、独立服务器等平台进行测试。该工具适用于运营商、企业、个人性能测试等场合。

2. Dbench

Dbench 是一项专项测试工具,可作为一个基准测试工具进行磁盘测试。对于需要测试文件系统 IO 性能的用户来说,Dbench 是一种好的选择。比如:测试磁盘的读写速度。Dbench 可通过多线程同时测试 IO 性能,压力测试的对象是 NFS 和其它文件系统。更大测试文件大小是 4GB,因此该工具适用于运营商、企业、个人测试磁盘性能的场合。

3. ApacheBenchmark

ApacheBenchmark 是专项测试工具中的一种,它主要用于测试 Web 服务器的负载压力,看系统在同一时间内支持的并发数。它主要测试 Web 服务器在并发请求下的响应速度,可以帮助我们找出网站或者系统中瓶颈所在。ApacheBenchmark 更大的特点是能够模拟具有不同访问量的请求,以便对服务器进行负载压力测试。该工具适用于需要测试云主机的 Web 服务性能的企业、运营商以及个人。

4. Super PI

Super PI 可以用来测试 CPU 的性能,主要是测试 CPU 浮点运算能力,优缺点和用途和 UnixBench 类似。Super PI 的测试结果主要为计算机执行小数点运算的时间时长,测试值越小表示 CPU 浮点运算能力越好。在进行 CPU 性能测试时,只能测试单核 CPU 的性能。该工具适用于个人及一些有小型 IT 需求的企业。

5. IPerf

IPerf 是网络 BP 的专项测试工具,可以用来测试网络带宽。该工具可以网络带宽测试同时测出延迟、抖动等指标,它无论是在本地网络测试还是远程网络测试都非常稳定。该工具对于需要测试云主机公网流量速度的企业、运营商及个人非常有用。

三、

云主机虽然具有很多优点,例如弹性伸缩、高安全性、可靠性等,但它的性能也是非常重要的考量因素之一。因此,如何评估和选择最适合自己的云主机成为了各个企业亟需解决的问题。以上介绍的云主机测试工具,可以分别针对不同的测试需求进行评测和选择,帮助企业快速找到最适合自己需求的云主机,提高业务的效率和稳定性。

相关问题拓展阅读:

如何测试云硬盘

问题

  UOS公有云开放以来,一些用户反应用dd命令测试出来的1TB云硬盘的吞吐率(MBPS)只有128MB/s,而不是我们SLA保证的170MB /s ,这是为什么?下面我会简单介绍如何测试硬盘,RAID,SAN,SSD,云硬盘等,然后再来回答上面的问题。

  测试前提

  我们在进行测试时,都会分清楚:

  测试对象:要区分硬盘、SSD、RAID、SAN、云硬盘等,因为它们有不同的特点

  测试指标:IOPS和MBPS(吞吐率),下面睁含备会具体阐述

  测试工具:Linux下常用Fio、dd工具, Windows下常用IOMeter,

  测试参数: IO大小,寻址空间,队列深度,读写模式,随机/顺序模式

  测试方法:也就是测试步骤。

  测试是为了对比,所以需要定性和定量。在宣布自己的测试结果时,需要说明这次测试的工具、参数、方法,以便于比较。

  存储系统模型

  为了更好的测试,我们需要先了解存储系统,块存储系统本质是一个排队模型,我们可以拿银行作为比喻。还记得你去银行办事时的流程吗?

  去前台取单号

  等待排在你之前的人办完业务

  轮到你去某个柜台

  柜台职员帮你办完手续1

  柜台职员帮你办完手续2

  柜台职员帮你办完手续3

  办完业务,从柜台离开

  如何评估银行的效率呢:

  服务时间 = 手续1 + 手续2 + 手续3

  响应时间 = 服务时间老橘 + 等待时间

  性能 = 单位时间内处理业务数量

  那银行如何提高效率呢:

  增加柜台数

  降低服务时间

  因此,排队系统或存储系统的优化方法是

  增加并行度

  降低服务时间

  硬盘测试

  硬盘原理

  我们应该如何测试SATA/SAS硬盘呢?首先需要了解磁盘的构造,并了解磁盘的工作方式:

  每个硬盘都有一个磁头(相当于银行的柜台),硬盘的工作方式是:

  收到IO请求,得到地址和数据大小

  移动磁头(寻址)

  找到相应的磁道(寻址)

  读取数据

  传输数据

  则磁盘的随机IO服务时间:

  服务时间 = 寻道时间 + 旋转时间 + 传输时间

  对于10000转速的SATA硬盘来说,一般寻道时间是7 ms,旋转时间是3 ms, 64KB的传输时间是 0.8 ms, 则SATA硬盘每秒可以进行随机IO操作是 1000/(7 + 3 + 0.8) = 93,所以我们估算SATA硬盘64KB随机写的IOPS是93。一般的硬盘厂商都会标明顺序读写的MBPS。

  我们在列出IOPS时,需要说明IO大小,寻址空间,读写模式,顺序/随机,队列深度。我们一般常用的IO大小是4KB,悉毁这是因为文件系统常用的块大小是4KB。

  使用dd测试硬盘

  虽然硬盘的性能是可以估算出来的,但是怎么才能让应用获得这些性能呢?对于测试工具来说,就是如何得到IOPS和MBPS峰值。我们先用dd测试一下SATA硬盘的MBPS(吞吐量)。

  #dd if=/dev/zero of=/dev/sdd bs=4k count=oflag=direct

  记录了300000+0 的读入 记录了300000+0 的写出字节(1.2 GB)已复制,17.958 秒,68.4 MB/秒

  #iostat -x sdd 5 10

  …

  Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

  sdd 0.00 0.00 0..80 0..40 8.00 0.79 0.05 0.05 78.82

  …

  为什么这块硬盘的MBPS只有68MB/s? 这是因为磁盘利用率是78%,没有到达95%以上,还有部分时间是空闲的。当dd在前一个IO响应之后,在准备发起下一个IO时,SATA硬盘是空闲的。那么如何才能提高利用率,让磁盘不空闲呢?只有一个办法,那就是增加硬盘的队列深度。相对于CPU来说,硬盘属于慢速设备,所有操作系统会有给每个硬盘分配一个专门的队列用于缓冲IO请求。

  队列深度

  什么是磁盘的队列深度?

  在某个时刻,有N个inflight的IO请求,包括在队列中的IO请求、磁盘正在处理的IO请求。N就是队列深度。

  加大硬盘队列深度就是让硬盘不断工作,减少硬盘的空闲时间。

  加大队列深度 -> 提高利用率 -> 获得IOPS和MBPS峰值 -> 注意响应时间在可接受的范围内

  增加队列深度的办法有很多

  使用异步IO,同时发起多个IO请求,相当于队列中有多个IO请求

  多线程发起同步IO请求,相当于队列中有多个IO请求

  增大应用IO大小,到达底层之后,会变成多个IO请求,相当于队列中有多个IO请求 队列深度增加了。

  队列深度增加了,IO在队列的等待时间也会增加,导致IO响应时间变大,这需要权衡。让我们通过增加IO大小来增加dd的队列深度,看有没有效果:

  dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct

  记录了1000+0 的读入 记录了1000+0 的写出字节(2.1 GB)已复制,10.6663 秒,197 MB/秒

  Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

  sdd 0.00 0.00 0.00 380.60 0…00 2.39 6.28 2.56 97.42

  可以看到2MB的IO到达底层之后,会变成多个512KB的IO,平均队列长度为2.39,这个硬盘的利用率是97%,MBPS达到了197MB/s。(为什么会变成512KB的IO,你可以去使用Google去查一下内核参数 max_sectors_kb的意义和使用方法 )

  也就是说增加队列深度,是可以测试出硬盘的峰值的。

  使用fio测试硬盘

  现在,我们来测试下SATA硬盘的4KB随机写的IOPS。因为我的环境是Linux,所以我使用FIO来测试。

  $fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb \

  -name=”EBS 4K randwrite test” -iodepth=64 -runtime=60

  简单介绍fio的参数

  ioengine: 负载引擎,我们一般使用libaio,发起异步IO请求。

  bs: IO大小

  direct: 直写,绕过操作系统Cache。因为我们测试的是硬盘,而不是操作系统的Cache,所以设置为1。

  rw: 读写模式,有顺序写write、顺序读read、随机写randwrite、随机读randread等。

  size: 寻址空间,IO会落在

  filename: 测试对象

  iodepth: 队列深度,只有使用libaio时才有意义。这是一个可以影响IOPS的参数。

  runtime: 测试时长

  下面我们做两次测试,分别 iodepth = 1和iodepth = 4的情况。下面是iodepth = 1的测试结果。

  上图中蓝色方框里面的是测出的IOPS 230, 绿色方框里面是每个IO请求的平均响应时间,大约是4.3ms。黄色方框表示95%的IO请求的响应时间是小于等于 9.920 ms。橙色方框表示该硬盘的利用率已经达到了98.58%。

  下面是 iodepth = 4 的测试:

  我们发现这次测试的IOPS没有提高,反而IO平均响应时间变大了,是17ms。

  为什么这里提高队列深度没有作用呢,原因当队列深度为1时,硬盘的利用率已经达到了98%,说明硬盘已经没有多少空闲时间可以压榨了。而且响应时间为 4ms。 对于SATA硬盘,当增加队列深度时,并不会增加IOPS,只会增加响应时间。这是因为硬盘只有一个磁头,并行度是1, 所以当IO请求队列变长时,每个IO请求的等待时间都会变长,导致响应时间也变长。

  这是以前用IOMeter测试一块SATA硬盘的4K随机写性能,可以看到IOPS不会随着队列深度的增加而增加,反而是平均响应时间在倍增。

  队列深度IOPS平均响应时间

..002217

..986528

..025060

..766359

..513477

..353934

..202315

..163111

..401781

  寻址空间对IOPS的影响

  我们继续测试SATA硬盘,前面我们提到寻址空间参数也会对IOPS产生影响,下面我们就测试当size=1GB时的情况。

  我们发现,当设置size=1GB时,IOPS会显著提高到568,IO平均响应时间会降到7ms(队列深度为4)。这是因为当寻址空间为1GB时,磁头需要移动的距离变小了,每次IO请求的服务时间就降低了,这就是空间局部性原理。假如我们测试的RAID卡或者是磁盘阵列(SAN),它们可能会用Cache把这1GB的数据全部缓存,极大降低了IO请求的服务时间(内存的写操作比硬盘的写操作快很1000倍)。所以设置寻址空间为1GB的意义不大,因为我们是要测试硬盘的全盘性能,而不是Cache的性能。

  硬盘优化

  硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟):

  提高转速(降低旋转时间和传输时间)

  增加Cache(降低写延迟,但不会提高IOPS)

  提高单磁道密度(变相提高传输时间)

  RAID测试

  RAID0/RAID5/RAID6的多块磁盘可以同时服务,其实就是提高并行度,这样极大提高了性能(相当于银行有多个柜台)。

  以前测试过12块RAID0,100GB的寻址空间,4KB随机写,逐步提高队列深度,IOPS会提高,因为它有12块磁盘(12个磁头同时工作),并行度是12。

  队列深度IOPS平均响应时间

..820237

..428420

..744060

..486629

..914048

..846616

..585251

..085843

..401606

  RAID卡厂商优化的方法也是降低服务时间:

  使用大内存Cache

  使用IO处理器,降低XOR操作的延迟。

  使用更大带宽的硬盘接口

  

  SAN测试

  对于低端磁盘阵列,使用单机IOmeter就可以测试出它的IOPS和MBPS的峰值,但是对于高端磁盘阵列,就需要多机并行测试才能得到IOPS和MBPS的峰值(IOmeter支持多机并行测试)。下图是纪念照。

  磁盘阵列厂商通过以下手段降低服务时间:

  更快的存储网络,比如FC和IB,延时更低。

  读写Cache。写数据到Cache之后就马上返回,不需要落盘。 而且磁盘阵列有更多的控制器和硬盘,大大提高了并行度。

  现在的存储厂商会找SPC帮忙测试自己的磁盘阵列产品(或全闪存阵列), 并给SPC支付费用,这就是裸的标准垄断。国内也有做存储系统测试的,假如你要测试磁盘阵列,可以找NSTC (广告时间)。

  SSD测试

  SSD的延时很低,并行度很高(多个nand块同时工作),缺点是寿命和GC造成的响应时间不稳定。

  推荐用IOMeter进行测试,使用大队列深度,并进行长时间测试,这样可以测试出SSD的真实性能。

  下图是storagereview对一些SSD硬盘做的4KB随机写的长时间测试,可以看出有些SSD硬盘的更大响应时间很不稳定,会飙高到几百ms,这是不可接受的。

  云硬盘测试

  我们通过两方面来提高云硬盘的性能的:

  降低延迟(使用SSD,使用万兆网络,优化代码,减少瓶颈)

  提高并行度(数据分片,同时使用整个集群的所有SSD)

  在Linux下测试云硬盘

  在Linux下,你可以使用FIO来测试

  操作系统:Ubuntu 14.04

  CPU: 2

  Memory: 2GB

  云硬盘大小: 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )

  安装fio:

  #sudo apt-get install fio

  再次介绍一下FIO的测试参数:

  ioengine: 负载引擎,我们一般使用libaio,发起异步IO请求。

  bs: IO大小

  direct: 直写,绕过操作系统Cache。因为我们测试的是硬盘,而不是操作系统的Cache,所以设置为1。

  rw: 读写模式,有顺序写write、顺序读read、随机写randwrite、随机读randread等。

  size: 寻址空间,IO会落在

  filename: 测试对象

  iodepth: 队列深度,只有使用libaio时才有意义。这是一个可以影响IOPS的参数。

  runtime: 测试时长

  4K随机写测试

  我们首先进行4K随机写测试,测试参数和测试结果如下所示:

  #fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb \

  -name=”EBS 4KB randwrite test” -iodepth=32 -runtime=60

  蓝色方框表示IOPS是5900,在正常的误差范围内。绿色方框表示IO请求的平均响应时间为5.42ms, 黄色方框表示95%的IO请求的响应时间是小于等于 6.24 ms的。

  4K随机读测试

  我们再来进行4K随机读测试,测试参数和测试结果如下所示:

  #fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb \

  -name=”EBS 4KB randread test” -iodepth=8 -runtime=60

  512KB顺序写测试

  最后我们来测试512KB顺序写,看看云硬盘的更大MBPS(吞吐率)是多少,测试参数和测试结果如下所示:

  #fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb \

  -name=”EBS 512KB seqwrite test” -iodepth=64 -runtime=60

  

  蓝色方框表示MBPS为174226KB/s,约为170MB/s。

  使用dd测试吞吐率

  其实使用dd命令也可以测试出170MB/s的吞吐率,不过需要设置一下内核参数,详细介绍在 128MB/s VS 170MB/s 章节中。

  在Windows下测试云硬盘

  在Windows下,我们一般使用IOMeter测试磁盘的性能,IOMeter不仅功能强大,而且很专业,是测试磁盘性能的首选工具。

  IOMeter是图形化界面(浓浓的MFC框架的味道),非常方便操作,下面我将使用IOMeter测试我们UOS上1TB的云硬盘。

  操作系统:Window Server 2023 R2 64

  CPU: 4

  Memory: 8GB

  云硬盘大小: 1TB

  当你把云硬盘挂载到Windows主机之后,你还需要在windows操作系统里面设置硬盘为联机状态。

  4K随机写测试

  打开IOMeter(你需要先下载),你会看到IOMeter的主界面。在右边,你回发现4个worker(数量和CPU个数相同),因为我们现在只需要1个worker,所以你需要把其他3个worker移除掉。

  

  现在让我们来测试硬盘的4K随机写,我们选择好硬盘(Red Hat VirtIO 0001),设置寻址空间(Maximum Disk Size)为50GB(每个硬盘扇区大小是512B,所以一共是 50*1024*1024*1024/512 =),设置队列深度(Outstanding I/Os)为64。

  然后在测试集中选择”4KiB ALIGNED; 0% Read; 100% random(4KB对齐,100%随机写操作)” 测试

  然后设置测试时间,我们设置测试时长为60秒,测试之前的预热时间为10秒(IOMeter会发起负载,但是不统计这段时间的结果)。

  在最后测试之前,你可以设置查看实时结果,设置实时结果的更新频率是5秒钟。最后点击绿色旗子开始测试。

  在测试过程中,我们可以看到实时的测试结果,当前的IOPS是6042,平均IO请求响应时间是10.56ms,这个测试还需要跑38秒,这个测试轮回只有这个测试。

  我们可以看到IOMeter自动化程度很高,极大解放测试人员的劳动力,而且可以导出CSV格式的测试结果。

  顺序读写测试

  我们再按照上面的步骤,进行了顺序读/写测试。下面是测试结果:

  IO大小读写模式队列深度MBPS

  顺序写吞吐测试512KB顺序写.07 MB/s

  顺序读吞吐测试256KB顺序读.32 MB/s

  云硬盘的响应时间

  当前云硬盘写操作的主要延迟是

  网络传输

  多副本,写三份(数据强一致性)

  三份数据都落盘(数据持久化)之后,才返回

  IO处理逻辑

  我们当前主要是优化IO处理逻辑,并没有去优化2和3,这是因为我们是把用户数据的安全性放在之一位。

  128MB/s VS 170MB/s

  回到最开始的问题 “为什么使用dd命令测试云硬盘只有128MB/s”, 这是因为目前云硬盘在处理超大IO请求时的延迟比SSD高(我们会不断进行优化),现在我们有两种方法来获得更高的MBPS:

  设置max_sectors_kb为256 (系统默认为512),降低延迟

  使用fio来测试,加大队列深度

  通过设置max_sectors_kb这个参数,使用dd也可以测出170MB/s的吞吐量

  root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb

  512

  root@ustack:~# echo “256” > /sys/block/vdb/queue/max_sectors_kb

  root@ustack:~#

  root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct

  40+0 records in

  40+0 records out

bytes (1.3 GB) copied, 7.51685 s, 179 MB/s

  root@ustack:~#

  同时查看IO请求的延迟:

  root@ustack:~# iostat -x vdb 5 100

  …

  Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

  vdb 0.00 0.00 0.00 688.00 0…00 54.59 93.47 0.00 93.47 1.40 96.56

  下面是使用fio工具的测试结果,也可以得到170MB/s的吞吐率。

  不可测试的指标

  IOPS和MBPS是用户可以使用工具测试的指标,云硬盘还有一些用户不可测量的指标

  数据一致性

  数据持久性

  数据可用性

  这些指标我们只能通过根据系统架构和约束条件计算得到,然后转告给用户。这些指标衡量着公有云厂商的良心,有机会会专门进行介绍。

  总结

  上面介绍了一下测试工具和一些观点,希望对你有所帮助。

  测试需要定性和定量

  了解存储模型可以帮助你更好的进行测试

  增加队列深度可以有效测试出IOPS和MBPS的峰值

  

  云硬盘,就是网盘。

  网盘的硬盘都是清斗服务器硬盘,不族正拿必用户操心或测试。只要速兆搭度快就行。

  可以用客户端上传下载试试速度即可。

云主机测试工具的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于云主机测试工具,「快速评测」——最新云主机测试工具大盘点,如何测试云硬盘的信息别忘了在本站进行查找喔。


数据运维技术 » 「快速评测」——最新云主机测试工具大盘点 (云主机测试工具)