COSBench是Intel团队基于java开发,对云存储的测试工具,全称是Cloud object Storage Benchhtml
吐槽下,貌似这套工具是intel上海团队开发的,居然没有中文的相关资料。java
同全部的性能测试工具同样,COSBench也分控制台和发起请求的driver,且driver能够分布式部署。能够支持swift、s三、Openstack等接口linux
下载地址为:https://github.com/intel-cloud/cosbench,必定要下载最新的包
否则可能会运行失败,本人就遇到启动失败的问题git
yum install java curl
COSBench底层调用了linux nc来作数据分析,因此若是linux没装nc的须要手工安装ncgithub
[root@test_rbd_01]# cd 0.4.2.c3 [root@test_rbd_01 0.4.2.c3]# chmod +x *.sh [root@test_rbd_01 0.4.2.c3]# unset http_proxy
直接运行./start_all.sh文件,会同时将control、driver同时运行,但driver只能在一台上启动,后续会说添加多台driverswift
启动成功后输入http://127.0.0.1:19088/controller/index.html就会出现页面,若是是在windows上查看,这里的ip须要换成linux的本机IP地址,并肯定19088端口是放行的。windows
以下图所示:centos
在这里遇到一个问题,每次启动后时区都显示不对,且发起请求后,时间也会更改,原来是要修改启动脚本cosbench-start.shtomcat
修改java启动以下:并发
/usr/bin/nohup java -Duser.timezone=Asia/Shanghai -Dcosbench.tomcat.config=$TOMCAT_CONFIG -server -cp main/* org.eclipse.equinox.launcher.Main -configuration $OSGI_CONFIG -console $OSGI_CONSOLE_PORT 1> $BOOT_LOG 2>&1 &
Control.conf的配置
配置基本信息及driver信息,
注意,driver必须以driver<n>的形式添加,否则没法识别,以下:
[driver1] name = driver1 url = http://*.11:18088/driver [driver2] name = driver2 url = http://*.12:18088/driver [driver3] name = driver3 url = http://*.13:18088/driver [driver4] name = driver4 url = http://*.14:18088/driver
Driver.conf的配置
配置你须要发起压力的dirver,能够不启动,若是没有启动,在controller overview中将看不到driver
若是要在不一样机器启动dirver,须要分别运行start-driver.sh,并确保通讯是否正常,能够经过 curl http://<dirver-host>:18088/driver/index.html肯定通讯是否正常
有不少模板的例子,在conf目录下,如librados-config-sample.xml、s3-config-sample.xml
这里只测试s3的接口,因此先关注s3的相关配置
S3的配置在页面上选择时没有显示出来,因此咱们就进行手工配置
<workstage name="prepare"> <storage type="s3" config="accesskey=<accesskey>;secretkey=<scretkey>;proxyhost=<proxyhost>;proxyport=<proxyport>;endpoint=<endpoint>" /> <work type="prepare" workers="1" config="cprefix=s3testqwer;containers=r(1,2);objects=r(1,10);sizes=c(64)KB" /> </workstage>
配置的说明以下(参考userGuide.pdf)
<workstage name="prepare">
属性 | 类型 | 默认值 | 备注 |
Name | String | 名字,随便取 |
<work type="prepare" workers="1" config="cprefix=s3testqwer;containers=r(1,2);objects=r(1,10);sizes=c(64)KB" />
这里插入pdf中的说明:
对于s3接口来讲,通常有下面几种work type: init、prepare、dispose、cleanup,具体能够参考demo文档
这里给出几个示例配置文档:
建立buckets
- <workload name="initBucket" description="sample benchmark for s3"> <storage type="s3" config="accesskey=V02TU7BTTHYSVINSRB7P;secretkey=b2u6ZgiNVlnfsDUpBigEbZKX9Na7kvM7UWEMrtPN;endpoint=http://xx.xx.xx.xx/" /> - <workflow> - <workstage name="init_create_bucket"> <work type="init" workers="1" config="cprefix=test;containers=r(1,2)" /> </workstage> </workflow> </workload>
获取数据
<?xml version="1.0" encoding="UTF-8" ?> - <workload name="get-100Workers-64k" description="sample benchmark for s3"> <storage type="s3" config="accesskey=V02TU7BTTHYSVINSRB7P;secretkey=b2u6ZgiNVlnfsDUpBigEbZKX9Na7kvM7UWEMrtPN;endpoint=http://xx.xx.xx.xx/" /> - <workflow> - <workstage name="get 64k data with 100 workers"> - <work name="Get64KBData" workers="25" totalOps="75000" driver="sv40"> <operation type="read" ratio="100" config="cprefix=test;oprefix=100wks_64k;containers=c(1);objects=u(1,75000)" /> </work> </workstage> </workflow> </workload>
这里的workers表示并发数,totalOps表示总的操做数,driver为不一样的压力机器,根据userGuide文档,里面有不少参数可选,以下:
属性 | 类型 | 默认值 | 说明 |
workers | 整型 | 必须配 | 并发数 |
interval | 整型 | 5s | 间隔时间 |
division | 字符 | "none" | 可选:[“none”| “container”| “object”] |
runtime | 整型 | 0 | 运行多长时间 |
rampup | 整型 | 0 | 多长时间启动完后全部的并发,与jmeter 中相似,与runtime冲突,不能一块儿配 |
rampdown | 整型 | 0 | 结束数,与runtime也不能一块儿配 |
上传数据
<?xml version="1.0" encoding="UTF-8" ?> - <workload name="put-100Workers-4MB" description="sample benchmark for s3"> <storage type="s3" config="accesskey=V02TU7BTTHYSVINSRB7P;secretkey=b2u6ZgiNVlnfsDUpBigEbZKX9Na7kvM7UWEMrtPN;endpoint=http://x.x.x.x/" /> - <workflow> - <workstage name="put 4MB data with 100 workers"> - <work name="Put64KBData1" workers="25" totalOps="75000" driver="sv40"> <operation type="write" ratio="100" config="cprefix=test;oprefix=100wks_64k;containers=c(1);objects=s(1,75000);sizes=c(4)MB" /> </work> </workstage> </workflow> </workload>
下图为测试完成后的一个结果截图
从图中咱们能够看到与任务一个压力工具都是的指标
一、Avg-ResTime 响应平均时间
二、Avg-ProcTime 平均处理时间
三、Throughput:吞吐量,也就是咱们常说的TPS
四、bandwith:带宽
五、succ-ratio :成功数
结果都是放在”archive”目录下了
这里有一个遗憾点是,性能测试中的资源监控没办法加入,好比cpu内存之类的,只能本身写脚本收集数据。