关于elasticsearch:如何对-ElasticSearch-集群进行压力测试

当 ElasticSearch 的业务量足够大，比方每天都会产生数百 GB 数据的时候，你就会自然而然的须要一个性能更强的 ElasticSearch 集群。特地是当你应用的场景是一些典型的大量数据进入的场景，比方网站日志、用户行为记录、大型电商网站的站内搜索时，一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下，如何找到一组适合的 ElasticSearch 集群？如何评估 ElasticSearch 集群的性能，就成为了一个非常重要的因素。

用什么 ElasticSearch 进行压力测试？

对于 ElasticSearch 性能测试和压力测试方面，其实有很多不同的计划，比方：

• Rally：Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。
• ESPerf：一个基于 Golang 编写的 ElasticSerch 性能测试工具
• Elasticsearch Stress Test：由驰名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具

除了这些定制化的工具意外以外，ElasticSearch 也能够借由其 Restful API 来应用 Load Runner、JMeter 等老牌工具进行测试，这些工具零零散散，各有各的用法和用处，不过，对于宽广开发者而言，还是官网出的 Rally 更令人满意。

在本篇文章中，将会应用 Rally 来实现 ElasticSearch 集群的压力测试

Rally 作为官网出品的工具，来自官网的信赖加成让他成为各家进行压力测试的首选工具。其次，Rally 官网给出了多种默认的数据集（Tracks）。如果你的应用场景笼罩在这些数据集 (比方 HTTP 拜访事件数据、天文名称数据、地理坐标点数据、HTTP 申请日志、问答场景、打车记录等场景) 中，能够间接应用已有的数据集，来实现测试，而无需制作测试数据。

即便你的场景比拟非凡，无奈被官网的数据集所笼罩，也仍然能够依据本人的线上数据，来创立数据集，确保测试成果的精确。

如何应用 Rally 进行测试？

在理解了 Rally 后，来具体看一看 Rally 的应用。

测试前的筹备

对于 Rally 的根本装置，这里就不再介绍，总的来说非常简略，在配置好了 JDK 和 Python 环境当前，只须要执行pip install rally 就能够实现装置。如果你的环境简单，心愿以一个更简略的形式来运行，你也能够抉择应用 Docker 来运行 Rally，进行测试。对于更多的装置形式，你能够参考 Rally 的装置文档.

在装置实现了 Rally 后，就能够开始进行 ElasticSearch 的测试。

在测试前，你须要先理解一些基本概念

• race：在 Rally 中，每一次测试都能够称之为 race
• car：在 Rally 中，每一个参加测试的集群，都能够称之为 car，不同的集群就是不同的 car，如果你是在选配置，则能够通过切换 car 来设置不同配置的测试。
• track: 在 Rally 中，每一次测试用的数据，都能够称之为 Track，不同的 Track 意味着不同的测试数据。
• challange：在 Rally 中，每一个 challange 意味着一个不同的测试场景，具体的场景则代表着 ElasticSearch 所执行的操作。

在理解测试的基本概念后，就能够开始进行压力测试。

进行压力测试

测试设施

因为本次测试实际上是一次选型的过程，在测试之前，我曾浏览了 Elastic 官网的权威指南中的硬件局部. 在其文档中提供了对于运行 ElasticSearch 集群设施的举荐配置。

1. 64 GB 内存的机器是十分现实的，然而 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会事与愿违（你最终须要很多很多的小机器），大于 64 GB 的机器也会有问题，咱们将在 堆内存: 大小和替换 中探讨。
2. 如果你要在更快的 CPUs 和更多的外围之间抉择，抉择更多的外围更好。多个内核提供的额定并发远胜过略微快一点点的时钟频率。
3. 如果你负担得起 SSD，它将远远超出任何旋转介质（注：机械硬盘，磁带等）。基于 SSD 的节点，查问和索引性能都有晋升。如果你负担得起，SSD 是一个好的抉择。
4. 通常，抉择中配或者高配机器更好。防止应用低配机器，因为你不会心愿去治理领有上千个节点的集群，而且在这些低配机器上运行 Elasticsearch 的开销也是显著的。

因而，我抉择了本来打算购买的三家厂商（阿里云、腾讯云、UCloud）的设施进行测试，在具体的配置层面，则在各家购买四台 8C64G 100GBSSD 磁盘的的云主机来进行测试。

测试环节

1. 构建集群

在进行测试前，须要先对已有的三台设施搭建集群，并配置集群链接，确保集群失常工作。集群搭建的局部，你能够参考官网文档中的 Add and remove nodes in your cluster 局部。

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/100th percentile latency: 提交申请和收到残缺回复之间的时间段，越小越好
• 50th/90th/99th/99.9th/100th percentile service time：申请解决开始和接管残缺响应之间的时间段，越小越好
• error rate：错误率，谬误响应绝对于响应总数的比例。任何被 Elasticsearch Python 客户端抛出的异样都被认为是谬误响应(例如，HTTP 响应码 4xx、5xx 或者网络谬误，如网络不可达)。

当你可能了解数据的划分形式后，对于 Rally 返回的泛滥数据就比拟好了解了。接下来，咱们以理论例子来看 Rally 返回的数据。

如何了解 Rally 返回的宏观测试数据

这里以我测试的数据为例。

依据每组数据对应的不同操作，咱们能够将其数据分为若干组，这里我将数据依照色彩进行了一个根底的划分，从上到下顺次为：

• 索引工夫
• 索引节流工夫
• 合并工夫
• 合并节流工夫
• 刷新工夫
• 重刷工夫

首先，先看第一组的索引工夫，索引工夫共有四个指标:

• Cumulative indexing time of primary shards: 主分片累计索引工夫
• Cumulative indexing time across primary shards：跨分片累计索引工夫
• Cumulative indexing throttle time of primary shards：主分片累计节流索引工夫
• Cumulative indexing throttle time across primary shards：跨分片累计节流索引工夫

这四个指标阐明了 ElasticSearch 在进行数据处理所须要的索引工夫，因而，工夫越短越好。

在本组测试后果中，腾讯云的计算工夫消耗最长，阿里云能够在腾讯的根底之上，有约 16 % 的性能晋升，UCloud 则在腾讯云的根底之上晋升了 24%。

在测试过程中，会因为机器的性能等因素，而造成理论测试工夫的不同。在这三组中，阿里云是最神奇的一个，因为它测试工夫达到了 6 个小时。而 UCloud 和腾讯云则别离在 3 小时和 4 小时左右，理论的测试体验还是有很大的差距。如果你要复现相应的试验，倡议你在早上进行，这样出测试后果的时候刚好还在白天。

接下来看合并工夫的数据

• Cumulative merge throttle time of primary shards：主分片累计节流合并工夫
• Min cumulative merge throttle time across primary shards：主分片累计节流合并工夫
• Median cumulative merge throttle time across primary shards：主分片累计节流中位合并工夫
• Max cumulative merge throttle time across primary shards：主分片累计节流最大合并工夫

合并工夫组后果相似于索引工夫组，不同的是测量的数据 Merge 工夫。和 index 相似，工夫越短越好，合并数量越大越好。

在本组测试后果中，腾讯云的计算工夫消耗最长，阿里云能够在腾讯的根底之上，有约 9 % 的性能晋升，UCloud 则在腾讯云的根底之上晋升了 30%～40%

其余几组相似的数据，这里就不再一一介绍，大家能够自行下载文章最初的数据进行剖析，评估，得出结论。

如何了解 Rally 返回的我的项目测试数据

除了宏观数据以外，Rally 返回数据中极大比例的是各种不同场景下的数据，这里，咱们也选两组数据进行比照剖析，看一看这些数据应该如何了解。

首先，咱们看一下 node-stats 组的后果。

node-stats 组的后果是针对 node-stats 命令的数据分析后果。这里的吞吐量越大越好，时延则越小越好。

在本组测试后果中，阿里云、腾讯云、UCloud 在性能方面没有较大的差距。

相似的，咱们能够比照 country_agg_uncached 组的后果

在本组测试后果中，阿里云、腾讯云、UCloud 在吞吐量方面没有较大的差距，时延方面 UCloud 会更好一点。

对于更多的数据，咱们不在这里一一介绍，我将测试数据曾经附在了文章的最初，你能够通过下载数据，自行剖析，来练习 Rally 的应用和数据分析。

一些应用 Rally 时的小技巧

如何解决 Rally 网络不好的问题？

Rally 在执行时，须要下载相应的数据进行实在场景下的模仿，在这种状况下，Rally 须要从 AWS S3 上下载一些数据包，用于本地的测试。但国内的设施对于 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 优于其余两家，是一个性价比 更高的抉择。当然，这是一个试验环境下的压测，还是须要依据具体的业务场景做测试来进行选型，更为迷信，不过心愿压测办法能给予大家参考，也欢送大家在后续理论的测试过程中给予我反馈。

附录

本文波及到的测试数据均能够在下载地址找到。