如何对 ElasticSearch 集群进行压力测试

发表于:2020-11-11 09:23

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:技术研究猿    来源:博客园

当ElasticSearch的业务量足够大,比如每天都会产生数百GB数据的时候,你就会自然而然的需要一个性能更强的ElasticSearch集群。特别是当你使用的场景是一些典型的大量数据进入的场景,比如网站日志、用户行为记录、大型电商网站的站内搜索时,一个强劲的ElasticSearch是必不可少的组件。在这样的场景下,如何找到一组合适的ElasticSearch集群?如何评估ElasticSearch集群的性能,就成为了一个十分重要的因素。
  用什么ElasticSearch进行压力测试
  对于ElasticSearch性能测试和压力测试方面,其实有很多不同的方案,比如:
  Rally:Rally是Elastic官方针对于ElasticSearch的宏观测试工具。
  ESPerf:一个基于Golang编写的ElasticSerch性能测试工具
  ElasticsearchStressTest:由著名的ElasticSearch服务提供商Logzio开发的性能测试工具
  除了这些定制化的工具意外以外,ElasticSearch也可以借由其RestfulAPI来使用LoadRunner、JMeter等老牌工具进行测试,这些工具零零散散,各有各的用法和用途,不过,对于广大开发者而言,还是官方出的Rally更令人满意。
  在本篇文章中,将会使用Rally来完成ElasticSearch集群的压力测试
  Rally作为官方出品的工具,来自官方的信任加成让他成为各家进行压力测试的首选工具。其次,Rally官方给出了多种默认的数据集(Tracks)。如果你的使用场景覆盖在这些数据集(比如HTTP访问事件数据、地理名称数据、地理坐标点数据、HTTP请求日志、问答场景、打车记录等场景)中,可以直接使用已有的数据集,来完成测试,而无需制造测试数据。
  即使你的场景比较特殊,无法被官方的数据集所覆盖,也依然可以根据自己的线上数据,来创建数据集,确保测试效果的准确。
  如何使用Rally进行测试?
  在了解了Rally后,来具体看一看Rally的使用。
  测试前的准备
  关于Rally的基本安装,这里就不再介绍,总的来说十分简单,在配置好了JDK和Python环境以后,只需要执行pipinstallrally就可以完成安装。如果你的环境复杂,希望以一个更简单的方式来运行,你也可以选择使用Docker来运行Rally,进行测试。
  在安装完成了Rally后,就可以开始进行ElasticSearch的测试。
  在测试前,你需要先了解一些基本概念
  race:在Rally中,每一次测试都可以称之为race
  car:在Rally中,每一个参与测试的集群,都可以称之为car,不同的集群就是不同的car,如果你是在选配置,则可以通过切换car来设置不同配置的测试。
  track:在Rally中,每一次测试用的数据,都可以称之为Track,不同的Track意味着不同的测试数据。
  challange:在Rally中,每一个challange意味着一个不同的测试场景,具体的场景则代表着ElasticSearch所执行的操作。
  在了解测试的基本概念后,就可以开始进行压力测试。
  进行压力测试
  测试设备
  由于本次测试实际上是一次选型的过程,在测试之前,我曾阅读了Elastic官方的权威指南中的硬件部分.在其文档中提供了对于运转ElasticSearch集群设备的推荐配置。
  64GB内存的机器是非常理想的,但是32GB和16GB机器也是很常见的。少于8GB会适得其反(你最终需要很多很多的小机器),大于64GB的机器也会有问题,我们将在堆内存:大小和交换中讨论。
  如果你要在更快的CPUs和更多的核心之间选择,选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
  如果你负担得起SSD,它将远远超出任何旋转介质(注:机械硬盘,磁带等)。基于SSD的节点,查询和索引性能都有提升。如果你负担得起,SSD是一个好的选择。
  通常,选择中配或者高配机器更好。避免使用低配机器,因为你不会希望去管理拥有上千个节点的集群,而且在这些低配机器上运行Elasticsearch的开销也是显著的。
  因此,我选择了原本打算购买的三家厂商(阿里云、腾讯云、UCloud)的设备进行测试,在具体的配置层面,则在各家购买四台8C64G100GBSSD磁盘的的云主机来进行测试。
  测试环节
  1.构建集群
  在进行测试前,需要先对已有的三台设备搭建集群,并配置集群链接,确保集群正常工作。
  2.执行测试命令
  在完成了集群的建设后,测试就简单很多,只需要执行命令,便可以对已经建设好的集群进行测试,比如:
esrally --track=pmc --target-hosts=10.5.5.10:9200,10.5.5.11:9200,10.5.5.12:9200 --pipeline=benchmark-only
  执行完命令后,接下来就是漫长的等待,根据机器的配置和集群等
  3.获得测试结果
  在执行了测试命令后,测试完成后,你就可以获得相应的测试结果。不过,为了方便进行对比和查看,你可以在测试的命令中加入参数,从而实现将测试结果导出为特定的格式。
  比如,执行这样的测试命令,就可以获得CSV格式的测试数据
esrally --track=pmc --target-hosts=10.5.5.10:9200,10.5.5.11:9200,10.5.5.12:9200 --pipeline=benchmark-only -report-format=csv --report-file=~/benchmarks/result.csv
  当你得到了csv的结果后,就可以对数据进行分析和对比了。
  如何查看Rally的测试结果
  当我们对Rally执行测试以后,我们会拿到大量的数据,而具体这些数据应该如何来看呢?接下来我们一一来看。
  如何理解Rally的数据
  Rally导出的数据共有4列,分别是Metric(维度)、Task(任务)、Unit(单位)和?Result(结果)。
  我们可以将数据按照Task进行切分,你可以得到若干组结果,如:
  没有Task的宏观数据
  index-append组数据
  index-stats组数据
  node-stats组数据
  phrase组数据
  ...
  不同的组意味着ElasticSearch在不同场景下的应用,因此,你在对比时,需要按照分组来看数据。而分组内部的数据,就简单了许多,除了宏观数据以外,其他各组的数据基本上都是一个模式的,具体可以分为以下14组数据。
  Min/Median/Max:本组测试的最小吞吐率、中位吞吐率和最大吞吐率,单位为ops/s,越大越好。
  50th/90th/99th/100thpercentilelatency:提交请求和收到完整回复之间的时间段,越小越好
  50th/90th/99th/99.9th/100thpercentileservicetime:请求处理开始和接收完整响应之间的时间段,越小越好
  errorrate:错误率,错误响应相对于响应总数的比例。任何被ElasticsearchPython客户端抛出的异常都被认为是错误响应(例如,HTTP响应码4xx、5xx或者网络错误,如网络不可达)。
  当你能够理解数据的划分方式后,对于Rally返回的众多数据就比较好理解了。接下来,我们以实际例子来看Rally返回的数据。
  如何理解Rally返回的宏观测试数据
  这里以我测试的数据为例。
  根据每组数据对应的不同操作,我们可以将其数据分为若干组,这里我将数据按照颜色进行了一个基础的划分,从上到下依次为:
  索引时间
  索引节流时间
  合并时间
  合并节流时间
  刷新时间
  重刷时间
  首先,先看第一组的索引时间,索引时间共有四个指标:
  Cumulativeindexingtimeofprimaryshards:主分片累计索引时间
  Cumulativeindexingtimeacrossprimaryshards:跨分片累计索引时间
  Cumulativeindexingthrottletimeofprimaryshards:主分片累计节流索引时间
  Cumulativeindexingthrottletimeacrossprimaryshards:跨分片累计节流索引时间
  这四个指标说明了ElasticSearch在进行数据处理所需要的索引时间,因此,时间越短越好。
  在本组测试结果中,腾讯云的计算时间耗费最长,阿里云可以在腾讯的基础之上,有约16%的性能提升,UCloud则在腾讯云的基础之上提升了24%。
  在测试过程中,会因为机器的性能等因素,而造成实际测试时间的不同。在这三组中,阿里云是最神奇的一个,因为它测试时间达到了6个小时。而UCloud和腾讯云则分别在3小时和4小时左右,实际的测试体验还是有很大的差距。如果你要复现相应的实验,建议你在早上进行,这样出测试结果的时候刚好还在白天。
  接下来看合并时间的数据
  Cumulativemergethrottletimeofprimaryshards:主分片累计节流合并时间
  Mincumulativemergethrottletimeacrossprimaryshards:主分片累计节流合并时间
  Mediancumulativemergethrottletimeacrossprimaryshards:主分片累计节流中位合并时间
  Maxcumulativemergethrottletimeacrossprimaryshards:主分片累计节流最大合并时间
  合并时间组结果类似于索引时间组,不同的是测量的数据Merge时间。和index类似,时间越短越好,合并数量越大越好。
  在本组测试结果中,腾讯云的计算时间耗费最长,阿里云可以在腾讯的基础之上,有约9%的性能提升,UCloud则在腾讯云的基础之上提升了30%~40%
  其他几组类似的数据,这里就不再一一介绍,大家可以自行下载文章最后的数据进行分析,评估,得出结论。
  如何理解Rally返回的项目测试数据
  除了宏观数据以外,Rally返回数据中极大比例的是各种不同场景下的数据,这里,我们也选两组数据进行对比分析,看一看这些数据应该如何理解。
  首先,我们看一下node-stats组的结果。
  node-stats组的结果是针对node-stats命令的数据分析结果。这里的吞吐量越大越好,时延则越小越好。
  如何解决Rally网络不好的问题?
  Rally在执行时,需要下载相应的数据进行真实场景下的模拟,在这种情况下,Rally需要从AWSS3上下载一些数据包,用于本地的测试。但国内的设备对于S3的访问不算太友好,经常会在下载的时候出现问题,因此,你可以选择前置下载数据,这样在测试的时候可以直接使用本地的数据来完成测试,减少失败的可能。
  想要前置下载数据也很简单只需要执行如下命令:
curl -O https://raw.githubusercontent.com/elastic/rally-tracks/master/download.sh
chmod u+x download.sh ./download.sh
geonames
cd ~
tar -xf rally-track-data-geonames.tar
  在执行download.sh时加入track名,就可以下载对应track数据的压缩包到本地,你可以根据自己的实际使用情况,来决定使用什么样的track模拟真实场景。
  总结
  在业务真正使用ElasticSearch之前,你可以像我一样,借助于Rally对备选的ElasticSearch集群进行压力测试,并通过对压测结果进行分析,从而获得明确的选型建议。比如,在我这次测试中,显然UCloud优于其他两家,是一个性价比更高的选择。当然,这是一个实验环境下的压测,还是需要根据具体的业务场景做测试来进行选型,更为科学,不过希望压测方法能给予大家参考,也欢迎大家在后续实际的测试过程中给予我反馈。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号