写在前面
我一直认为,任何一个组件的开发者在编写user guide的时候都应该秉持这样一个思路:
最快的,最方便的先让用户能把这个组件跑起来。
各种优化细节应该后面再说,而不是一上来就给用户说一大堆琐碎的知识点。
make it run!
make it right!
make it fast!
COSBench的定位与基本概念
COSBench是一个对对象存储系统进行压测的工具。内部包括controller driver等几个组件。
至于怎么把COSBench这个平台启动起来,往上有一堆例子。大家参考就好。
提交测试任务
提交测试任务,分两步,第一步就是先把xml格式的测试脚本写好。第二步就是提交任务。
先说第二步,提交任务也分两种
提交方法1 命令行提交
sh cli.sh submit conf/s3-config-sample-1951.xml
提交方式2 操作界面提交
在 http://{controller_ip}:19088/controller/index.html 里点击 submit new workloads 然后在新界面里选择文件即可
然后在界面上就可以看到任务的执行进度了。
具体的excel格式的结果在安装目录的archive下。
编写测试脚本
一个例子
我先抛出一个能运行的脚本,然后一个一个解释里面的内容。
<?xml version="1.0" encoding="UTF-8" ?>
<workload name="s3-sample" description="sample benchmark for s3">
<storage type="s3" config="accesskey=abc;secretkey=abc;endpoint=http://12.34.56.78:9000" />
<workflow>
<workstage name="init">
<work type="init" workers="1" config="cprefix=mytest;containers=r(3,4)" />
</workstage>
<workstage name="prepare">
<work type="prepare" workers="1" config="cprefix=mytest;containers=r(3,4);objects=r(1,300);sizes=c(64)KB" />
</workstage>
<workstage name="main">
<work type="normal" name="main_read" workers="1" runtime="12" >
<operation type="read" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=u(1,50)" />
</work>
<work type="normal" name="main_del" workers="1" runtime="12">
<operation type="delete" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=s(51,300)" />
</work>
<work type="normal" name="main_write" workers="1" runtime="12">
<operation type="write" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=s(301,400);sizes=c(64)KB" />
</work>
<work type="normal" name="main_list" workers="1" runtime="12">
<operation type="list" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=u(201,300)" />
</work>
</workstage>
<workstage name="cleanup">
<work type="cleanup" workers="1" config="cprefix=mytest;containers=r(3,4);objects=r(1,400)" />
</workstage>
<workstage name="dispose">
<work type="dispose" workers="1" config="cprefix=mytest;containers=r(3,4)" />
</workstage>
</workflow>
</workload>
xml解析
上面的xml里
- storage 后面的那些属性 步解释
- workstage 可以理解为测试的一个一个阶段。可以理解为测试前的基础数据准备,执行测试,清理测试数据等等都是一个一个workstage 。本次xml里,有4个workstage,他们是按照顺序执行的。
- work 隶属与一个workstage,大家就理解他为一组执行任务的客户端把。
- operation 具体执行的工作。
基本的概念如上,大家看xml里,有个work内部还包含了operation,有的不包含,这是为什么呢?
因为work分两种,一种叫用户自定义work,一种叫官方定义work。
先说官方定义work,它的type可以分为init、prepare、cleanup、dispose、delay。
- init 创立特定的桶
- prepare 写文件
- cleanup 清理文件
- dispose 清理桶
- delay 没看懂,说是延迟写,每用过
上面的既然是官方定义的work,已经明确了需要做什么任务了,那自然就不用再加operation了。
详细拆解
<workstage name="init">
<work type="init" workers="1" config="cprefix=mytest;containers=r(3,4)" />
</workstage>
上面依次创建两个桶,通名分别为mytest3,mytest4。
<workstage name="prepare">
<work type="prepare" workers="1" config="cprefix=mytest;containers=r(3,4);objects=r(1,300);sizes=c(64)KB" />
</workstage>
上面依次给两个桶里写文件,每个文件的大小都是64KB,文件名是一个默认前缀加编号,编号是从1到300。
<work type="normal" name="main_read" workers="1" runtime="12" >
<operation type="read" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=u(1,50)" />
</work>
这个work需要一直执行,执行12s之后退出(别的退出条件还包括执行一定的次数后退出)。
先从mytest3里面随机读取编号为1-50的对象
再次mytest4里面随机读取编号为1-50的对象
u(1,50)和r(1,300)的区别是什么?
u 代表随机 r代表顺序的一个个选择
<work type="normal" name="main_del" workers="1" runtime="12">
<operation type="delete" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=s(51,300)" />
</work>
以上,
先从mytest3里面顺序删除编号为51-300的对象
再次mytest4里面顺序读取编号为51-300的对象
s(51,300) 和 r(1,300)区别在哪?
都是顺序,但是s用于用户自定义的worker
r 用于官方的那些(init、prepare、cleanup、dispose)worker
具体来说
官方(init,prepar) | 自定义 | |
---|---|---|
顺序 | r | s |
随机 | u | u |
<work type="normal" name="main_list" workers="1" runtime="12">
<operation type="list" ratio="100" config="cprefix=mytest;containers=s(3,4);objects=u(201,300)" />
</work>
这个list 我觉得就应该是list object,但是不敢确定。
operation 的type有哪些:read,write,delete,list,filewrite等等
一个workstage 里面的多个work是并行执行的。
一个机器上可以启动多个driver
请参考
https://blog.csdn.net/weixin_43860781/article/details/121101694
一些心得
1 read的数据必须存在,否则会terminted
2 增加worker的并发数,可以以更大的带宽去测试COS(特别批量读写小文件)
参考资料
https://blog.csdn.net/mpu_nice/article/details/108235226