如何對 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 在進行數據處理所須要的索引時間，所以，時間越短越好。

Metric	騰訊雲	UCloud	阿里雲
Cumulative indexing time of primary shards	25.262833333333300	19.2662	21.40011666666670
Min cumulative indexing time across primary shards	5.0297	3.8177666666666700	4.2537666666666700
Median cumulative indexing time across primary shards	5.052066666666670	3.8252333333333300	4.272083333333330
Max cumulative indexing time across primary shards	5.076316666666670	3.9190666666666700	4.3139

在本組測試結果中，騰訊雲的計算時間耗費最長，阿里雲能夠在騰訊的基礎之上，有約 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 相似，時間越短越好，合併數量越大越好。

Metric	騰訊雲	UCloud	阿里雲	Unit
Cumulative merge time of primary shards	12.6379	7.717366666666670	11.083600000000000	min
Cumulative merge count of primary shards	90	116	99
Min cumulative merge time across primary shards	2.2037	1.43605	1.8695333333333300	min
Median cumulative merge time across primary shards	2.5391166666666700	1.5713166666666700	2.2406333333333300	min
Max cumulative merge time across primary shards	2.733966666666670	1.6538166666666700	2.5342	min

在本組測試結果中，騰訊雲的計算時間耗費最長，阿里雲能夠在騰訊的基礎之上，有約 9 % 的性能提高，UCloud 則在騰訊雲的基礎之上提高了 30%～40%

其餘幾組相似的數據，這裏就再也不一一介紹，你們能夠自行下載文章最後的數據進行分析，評估，得出結論。

如何理解 Rally 返回的項目測試數據

除了宏觀數據之外，Rally 返回數據中極大比例的是各類不一樣場景下的數據，這裏，咱們也選兩組數據進行對比分析，看一看這些數據應該如何理解。

首先，咱們看一下 node-stats 組的結果。

node-stats 組的結果是針對 node-stats 命令的數據分析結果。這裏的吞吐量越大越好，時延則越小越好。

Metric	Task	騰訊雲	UCloud	阿里雲	Unit
Min Throughput	node-stats	90.07	90.07	90.07	ops/s
Median Throughput	node-stats	90.11	90.11	90.12	ops/s
Max Throughput	node-stats	90.39	90.44	90.42	ops/s
50th percentile latency	node-stats	2.1798378893436200	1.491405833803580	1.8348334997426700	ms
90th percentile latency	node-stats	2.521278689346220	1.8698435997976000	1.9605179221798600	ms
99th percentile latency	node-stats	3.795880397665310	3.173550112005610	2.901402467268780	ms
99.9th percentile latency	node-stats	12.884928510055500	9.625145497986580	17.55732728102550	ms
100th percentile latency	node-stats	18.134295778509100	10.29519444455220	20.23470633321270	ms
50th percentile service time	node-stats	2.111824500389050	1.4231965001272300	1.7749374997038100	ms
90th percentile service time	node-stats	2.453031599361570	1.7979749004553000	1.8996412000888100	ms
99th percentile service time	node-stats	3.686133219835030	2.9536031294901500	2.8262974901645100	ms
99.9th percentile service time	node-stats	12.818092870313500	9.55140776220657	8.42020982098726	ms
100th percentile service time	node-stats	16.345433999958900	10.22649399965300	20.173265999801500	ms

在本組測試結果中，阿里雲、騰訊雲、UCloud 在性能方面沒有較大的差距。

相似的，咱們能夠對比 country_agg_uncached 組的結果

Metric	Task	騰訊雲	UCloud	阿里雲	Unit
Min Throughput	country_agg_uncached	3.60	3.61	3.60	ops/s
Median Throughput	country_agg_uncached	3.60	3.61	3.60	ops/s
Max Throughput	country_agg_uncached	3.60	3.61	3.61	ops/s
50th percentile latency	country_agg_uncached	259.7333187786720	116.19688144446600	197.52657255594400	ms
90th percentile latency	country_agg_uncached	264.3554400450740	125.7470980999640	201.85445903407500	ms
99th percentile latency	country_agg_uncached	270.25939978284400	132.88548155585000	205.84624599263400	ms
100th percentile latency	country_agg_uncached	278.76161922358700	133.7250455553660	206.57134322209500	ms
50th percentile service time	country_agg_uncached	259.5503135007680	115.99637649987900	197.4296050002520	ms
90th percentile service time	country_agg_uncached	264.2378849999660	125.53214089985000	201.7642059001450	ms
99th percentile service time	country_agg_uncached	270.08045803115200	132.6980350402570	205.7533532799970	ms
100th percentile service time	country_agg_uncached	278.6570290008970	133.52231299995800	206.47192300020800	ms
error rate	country_agg_uncached	0.00	0.00	0.00	%

在本組測試結果中，阿里雲、騰訊雲、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 優於其餘兩家，是一個性價比 更高的選擇。固然，這是一個實驗環境下的壓測，仍是須要根據具體的業務場景作測試來進行選型，更爲科學，不過但願壓測方法能給予你們參考，也歡迎你們在後續實際的測試過程當中給予我反饋。

附錄

本文涉及到的測試數據都可以在下載地址找到。