• 0
  • 0
分享
  • 使用 YCSB 和 PE 进行 HBase 性能压力测试——软件测试圈
  • 饼干 2024-10-28 16:18:23 字数 5580 阅读 282 收藏 0

  HBase主要性能压力测试有两个,一个是 HBase 自带的 PE,另一个是 YCSB,先简单说一个两者的区别。PE 是 HBase 自带的工具,开箱即用,使用起来非常简单,但是 PE 只能按单个线程统计压测结果,不能汇总整体压测数据,更重要的是,PE 没有 YCSB 的 预设模板(Workload) 功能,测试场景单一,相较而言,YCSB 要强大的多,它的 Workload 功能非常实用,可以模拟更贴近实际使用场景的压力状况。下面分解介绍一下两款工具的使用方法。

  1. YCSB

  官方文档: https://github.com/brianfrankcooper/YCSB/blob/master/asynchbase/README.md

  1.1 全局配置

  hbaseYcsbUrl="https://github.com/brianfrankcooper/YCSB/releases/download/0.17.0/ycsb-hbase20-binding-0.17.0.tar.gz"
  hbaseYcsbPkg=$(basename $hbaseYcsbUrl)
  hbaseYcsbDir=$(basename $hbaseYcsbUrl ".tar.gz")
  export YCSB_HOME="/opt/$hbaseYcsbDir"

  1.2. 下载

  下载地址: https://github.com/brianfrankcooper/YCSB/releases

  wget $hbaseYcsbUrl -P /tmp/
  sudo tar -xzf /tmp/$hbaseYcsbPkg -C /opt
  $YCSB_HOME/bin/ycsb -h

  1.3. 建表

  cat << EOF | hbase shell
  disable 'usertable'
  drop 'usertable'
  n_splits = 30 # HBase recommends (10 * number of regionservers)
  create 'usertable', 'cf', {SPLITS => (1..n_splits).map {|i| "user#{1000+i*(9999-1000)/n_splits}"}}
  describe 'usertable'
  EOF

  1.4. 加载数据

  $YCSB_HOME/bin/ycsb load hbase20 -cp /etc/hbase/conf/ -p columnfamily=cf -P $YCSB_HOME/workloads/workloada

  上述数据加载使用的是方案/模板:workloada(就是一个properties文件),该方案默认写入1000条记录,并执行1000次操作(read,update,scan等),用户可以自定插入的数据量和操作次数,例如:-p recordcount=10000 -p operationcount=10000。这里再详细说明 一下recordcount和operationcount两个属性:

  · recordcount :总的插入数据量,写入数据的操作不会算到operationcount里面

  · operationcount:总的操作次数,操作被分成了read、update、scan、insert四种类型,可以在配置中设定它们之间的比例,但总的操作次数是由operationcount控制的

  1.5. 确认数据是否加载成功

  cat << EOF | hbase shell
  scan 'usertable'
  EOF

  1.6. 选择压测模板(Workload)

  上述加载数据的测试仅仅是一个“冒烟”测试,实际进行压测前,要根据目标场景选择一个相匹配的 Workload,当然,也可以完全自定义 Workload,以下是存放在$YCSB_HOME/workloads下的6种预定义的 Workload:

1.png

  1.7. 正式压测

  了解了上述不同类型的 Workload 后,选择一个符合自身集群使用场景的 Workload,然后就可以正式压测了,以下以workloadb为例:

  nohup $YCSB_HOME/bin/ycsb run hbase20 \
      -cp /etc/hbase/conf/ \
      -p columnfamily=cf \
      -p recordcount=10000000 \
      -p operationcount=10000000 \
      -P $YCSB_HOME/workloads/workloadb \
      -threads 3 \
      -s &> nohup.out &
  tail -f nohup.out

  压测执行完毕后会给出类似下图的压测报告:

1-1.png

  2. PE

  PE只能统计每个线程执行的情况,不能统计整体的状态,所以还是推荐使用YCSB。

  2.1 建表并执行测试

  cat << EOF | hbase shell
  create 'test-table', {NAME => 'f', REPLICATION_SCOPE=>'1'}
  EOF
  hbase pe --nomapred --oneCon=true --table=test-table --rows=1000000 --valueSize=100 --compress=SNAPPY --presplit=16 --autoFlush=true randomWrite 16

  PE的测试报告并不在控制台直接输出(这一点不太好),而是写入到了HBase的LOG文件,如果是EMR,会写到/var/log/hbase/hbase.log中,PE会分别打出每个线程的延迟状况,类似下面这样:

1-2.png

  3. 附录

  3.1. PE 命令行参数

  General Options:
   nomapred        采用MapReduce的方式启动多线程测试还是通过多线程的方式,如果没有安装MapReduce,或者不想用MapReduce,通常我们采用多线程的方式,因此一般在命令中加上--nomapred来表示不使用MapReduce。  
   rows            每个客户端(线程)运行的行。默认值:一百万。注意这里的行数是指单线程的行数,如果rows=100, 线程数为10,那么在写测试中,写入HBase的将是 100 x 10 行  
   size            总大小,单位GiB。与--rows互斥。默认值:1.0。  
   sampleRate      样本比例:对总行数的一部分样本执行测试。只有randomRead支持。默认值:1.0  
   traceRate       启用HTrace跨度。每N行启动一次跟踪。默认值:0  
   table           测试表的名字,如果不设,默认为TestTable。  
   multiGet        如果> 0,则在执行RandomRead时,执行多次获取而不是单次获取。默认值:0  
   compress        要使用的压缩类型(GZ,LZO,...)。默认值:'无'  
   flushCommits    该参数用于确定测试是否应该刷新表。默认值:false  
   writeToWAL      在puts上设置writeToWAL。默认值:True  
   autoFlush       默认为false,即PE默认用的是BufferedMutator,BufferedMutator会把数据攒在内存里,达到一定的大小再向服务器发送,如果想明确测单行Put的写入性能,建议设置为true。个人觉得PE中引入autoFlush会影响统计的准确性,因为在没有攒够足够的数据时,put操作会立马返回,根本没产生RPC,但是相应的时间和次数也会被统计在最终结果里。  
   oneCon          多线程运行测试时,底层使用一个还是多个链接。这个参数默认值为false,每个thread都会启一个Connection,建议把这个参数设为True  
   presplit        表的预分裂region个数,在做性能测试时一定要设置region个数,不然所有的读写会落在一个region上,严重影响性能  
   inmemory        试图尽可能保持CF内存的HFile。不保证始终从内存中提供读取。默认值:false  
   usetags         与KV一起写标签。与HFile V3配合使用。默认值:false  
   numoftags       指定所需的标签号。仅当usetags为true时才有效。  
   filterAll       通过不将任何内容返回给客户端,帮助过滤掉服务器端的所有行。通过在内部使用FilterAllFilter,帮助检查服务器端性能。  
   latency         设置为报告操作延迟。默认值:False  
   bloomFilter     Bloom 过滤器类型,[NONE,ROW,ROWCOL]之一  
   valueSize       写入HBase的value的size,单位是Byte,大家可以根据自己实际的场景设置这个Value的大小。默认值:1024  
   valueRandom     设置是否应该在0和'valueSize'之间改变值大小;设置读取大小的统计信息:默认值: Not set.  
   valueZipf       设置是否应该以zipf格式改变0和'valueSize'之间的值大小, 默认值: Not set.  
   period          报告每个'period'行:默认值:opts.perClientRunRows / 10  
   multiGet        批处理组合成N组。只有randomRead支持。默认值: disabled  
   replicas        启用区域副本测试。默认值:1。  
   splitPolicy     为表指定自定义RegionSplitPolicy。  
   randomSleep     在每次获得0和输入值之前进行随机睡眠。默认值:0  
   Note: -D properties will be applied to the conf used.   
    For example:   
     -Dmapreduce.output.fileoutputformat.compress=true  
     -Dmapreduce.task.timeout=60000  
  Command:  
   filterScan      使用过滤器运行扫描测试,根据它的值查找特定行(确保使用--rows = 20)   
   randomRead      运行随机读取测试  
   randomSeekScan  运行随机搜索和扫描100测试  
   randomWrite     运行随机写测试  
   scan            运行扫描测试(每行读取)  
   scanRange10     使用开始和停止行(最多10行)运行随机搜索扫描  
   scanRange100    使用开始和停止行运行随机搜索扫描(最多100行)  
   scanRange1000   使用开始和停止行(最多1000行)运行随机搜索扫描  
   scanRange10000  使用开始和停止行运行随机搜索扫描(最多10000行)  
   sequentialRead  运行顺序读取测试  
   sequentialWrite 运行顺序写入测试  
  Args:  
   nclients        整数。必须要有该参数。客户端总数(和HRegionServers)  
  running: 1 <= value <= 500  
  Examples:  
   运行一个单独的客户端:  
   $ bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation sequentialWrite 1

  3.2. 百分位数值(Percentile):P99,P999

  百分位数值是一个统计学中的术语,通俗一点解释是:把所有的请求响应时间按从小到大的顺序排列起来,排在某个百分比位置上的请求响应时间就是这个百分比对应的百分位数值。举个例子就是明白了:

  P99:响应耗时从小到大排列,处在99%位置上的耗时即为P99值。假设该值为200ms,就意味着:99%的用户的响应耗时在200ms之内,只有1%的用户的响应耗时大于200ms

  P99.9 ( P999 ):许多互联网公司会采用P99.9值,也就是99.9%的用户耗时作为指标,通过测量与优化该值,就可保证绝大多数用户的使用体验。 至于P99.99值,优化成本过高,而且服务响应由于网络波动、系统抖动等不能解决之情况,因此大多数时候都不考虑该指标。


作者:Laurence    

来源:http://www.51testing.com/html/16/n-7798716.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   尽管自动化测试可以生成简洁的html测试报告,但是Testng自带的模板往往还是不够用。如果想要更加漂亮的数据和样式,就需要自己手动写模板。虽然有很多代码生成器,可以轻而易举的生成想要的模板样式代码,但是修改啊,配置啊多多少少还是会花一些时间,有时候若稍有不慎,调整布局就会弄花眼。如果使用成熟的用例管理工具,那么只要有测试结果,测试报告就可以自动生成了,比如使用testlink导出测试报告,则可以省去不少精力和时间了。如果想亲自设计一套符合自己审美的测试报告模板,这里推荐一个免费的工具MagicalCoder,H5页面布局可以在线使用,拖拖拽拽弄好布局后就可以获得源码,不懂前端代码的测试同...
            12 12 3880
            分享
          •   纵观软件测试行业的发展史,相信很多人都知道它是伴随着“软件”而出现的。  在早期软件开发的过程中,“测试”的含义其实是比较狭窄的,测试这一行为也完全由开发人员执行,几乎等同于“调试”工作。  到了上世纪80年代,IT行业得到了大力的发展,“软件”也趋向于大型化、高复杂度,这个时候“软件测试”才逐渐形成了自己的理论基础和实用技术。  从上世纪90年代开始,软件行业的发展形势可谓迅猛。随着软件行业规模变大,“软件测试”活动也变得需要更多的时间和成本了。  又经过20年的持续发展,“软件测试”行业已经有了自己的行业标准(IEEE/ANSI ),也经历了手工测试到自动化测试的技术变革,更是形成了自...
            0 1 1101
            分享
          • 读者提问:简易好用的在线 PS 工具有推荐的吗 ?阿常回答:有,稿定设计 / Canva可画 / 图司机。官网地址:https://www.gaoding.com/(稿定设计)https://www.canva.cn/(Canva可画)https://www.tusij.com/(图司机)阿常碎碎念:我们在平时工作生活中会遇到处理图片的需求,但不想额外在电脑上安装一个 PS 软件,期望可以直接浏览器访问、在线操作。以上三款在线 PS 工具均能满足日常图片处理的需求,但比较下来,阿常觉得稿定设计的用户体验更佳,更加推荐大家使用。看完今天的分享对你是不是有所启发呢,有任何想法都欢迎大家后...
            0 0 658
            分享
          • 随着智能手机的普及,移动app测试越来越重要。现在很多互联网都把注意精力放在了移动端,移动app尽量提供完美的用户体验。但是诸如崩溃,冻结问题,加载时间慢,不直观的导航以及侵犯隐私之类的严重错误可能会触发用户立即卸载应用程序。现在,移动应用程序已成为我们日常微时刻不可或缺的一部分,人们平均每天花费3-4个小时。移动应用在职业和个人生活中对每个人都起着关键作用。因此,手机移动端测试在构建移动应用程序以提供流畅的用户体验和功能方面扮演着重要角色。移动应用测试金字塔软件测试的人都知道Mike Cohn的测试自动化金字塔。典型的金字塔由三层组成。顶部是自动化集成测试层的中间,是一个自动化的端到端测试层...
            1 0 1876
            分享
          •   通过执行发现,我们在用例03中没有加入fixture,所有他没有执行一些用例的前置和后置操作。  测试报告  unittest:unittest中没有自带的测试报告,需要下载第三方的插件HTMLTestRunner和BeautifulReport来生成详细的测试报告。  pytest:pytest中也没有自带的测试报告,需要下载第三方插件pytest-html或者allure-pytest进行生成详细的测试报告。class Test01:     def test_01(self):     ...
            11 11 828
            分享
      • 51testing软件测试圈微信