Когда бизнес-объем ElasticSearch достаточно велик, например, сотни ГБ данных генерируются каждый день, вам, естественно, потребуется более мощный кластер ElasticSearch. Мощный ElasticSearch является важным компонентом, особенно когда вы используете типичные сценарии, в которые вводится большой объем данных, таких как журналы веб-сайтов, записи о поведении пользователей и поиск по сайту крупных веб-сайтов электронной коммерции. Как в таком случае найти подходящий набор кластеров ElasticSearch? Как оценить производительность кластера ElasticSearch становится очень важным фактором.
Какой ElasticSearch используется для стресс-тестирования?
Для тестирования производительности ElasticSearch и стресс-тестирования на самом деле существует множество различных решений, таких как:
- Rally: Rally — это официальный инструмент Elastic для тестирования макросов для ElasticSearch.
- ESPerf: Инструмент тестирования производительности ElasticSearch на основе Golang.
- Elasticsearch Stress Test: инструмент для тестирования производительности, разработанный известным поставщиком услуг ElasticSearch Logzio.
В дополнение к этим настроенным инструментам ElasticSearch также может использовать свой Restful API для использования старых инструментов, таких как Load Runner и JMeter для тестирования.Эти инструменты разбросаны и имеют свое собственное использование и цели, но для большинства разработчиков с точки зрения официального Ралли, это больше сытно.
В этой статье Rally будет использоваться для завершения стресс-теста кластера ElasticSearch.
Как официальный инструмент, официальный бонус доверия Ралли делает его предпочтительным инструментом для стресс-тестирования. Во-вторых, Rally официально предоставляет различные наборы данных по умолчанию (треки). Если ваши сценарии использования охватываются этими наборами данных (например, данные о событиях доступа HTTP, данные о географических названиях, данные о географических координатах, журналы HTTP-запросов, сценарии вопросов и ответов, записи такси и т. д.), вы можете напрямую использовать существующие наборы данных для Полное тестирование без данных производственных испытаний.
Даже если ваш сценарий особенный и не может быть охвачен официальным набором данных, вы все равно можете создать набор данных на основе ваших собственных онлайн-данных, чтобы обеспечить точные результаты тестирования.
Как использовать Rally для тестирования?
Узнав о Rally, давайте взглянем на использование Rally.
Подготовка перед тестом
Здесь не будет представлена базовая установка Rally, в целом она очень проста, после настройки среды JDK и Python нужно только выполнитьpip install rallyдля завершения установки. Если ваша среда сложна и вам нужен более простой способ ее запуска, вы также можете использовать Docker для запуска Rally для тестирования. Чтобы узнать больше о способах установки, вы можетеСм. документацию по установке Rally..
После установки Rally можно приступать к тестированию ElasticSearch.
Перед тестированием необходимо понять некоторые основные понятия
- race: В ралли каждое испытание можно назвать гонкой
- car: В Rally каждый кластер, участвующий в тесте, можно назвать автомобилем.Разные кластеры - разные автомобили.При выборе конфигурации можно настроить тесты с разными конфигурациями, переключив автомобиль.
- дорожка: в Rally данные, используемые для каждого теста, могут называться дорожкой, а разные дорожки означают разные данные испытаний.
- вызов: в Rally каждый вызов означает отдельный тестовый сценарий, а конкретный сценарий представляет собой операцию, выполняемую ElasticSearch.
Как только вы поймете основные концепции тестирования, вы можете приступить к стресс-тестированию.
Проведите стресс-тест
Испытательное оборудование
Поскольку этот тест на самом деле является процессом отбора, перед тестом я прочитал официальное авторитетное руководство Elastic.Аппаратные части.рекомендованная конфигурация для запуска устройств кластера ElasticSearch в документации.
- Идеально подходят машины с 64 ГБ ОЗУ, но также распространены машины с 32 ГБ и 16 ГБ. Менее 8 ГБ контрпродуктивно(В конечном итоге вам потребуется много-много маленьких машин), машины размером более 64 ГБ также будут иметь проблемы, которые мы обсудим в кучи памяти: размер и подкачка.
- Если вы выбираете между более быстрыми процессорами и большим количеством ядер, чем больше ядер, тем лучше.. Дополнительный параллелизм, обеспечиваемый несколькими ядрами, перевешивает немного более высокую тактовую частоту.
- Если вы можете позволить себе SSD, он выйдет далеко за рамки любых вращающихся носителей (примечание: механические жесткие диски, ленты и т. д.).Узлы на основе SSD, улучшена производительность запросов и индексов.. Если вы можете себе это позволить, SSD — хороший выбор.
- Обычно лучше выбирать машину средней или высокой комплектации. Избегайте бюджетных машин, потому что вы не хотите управлять кластерами с тысячами узлов, а накладные расходы на запуск Elasticsearch на этих машинах с низкими характеристиками значительны.
Поэтому я выбрал для тестирования оборудование трех производителей (Alibaba Cloud, Tencent Cloud и UCloud), которое изначально планировал закупить.На уровне конкретной конфигурации я приобрел для тестирования четыре облачных хоста с SSD-дисками 8C64G 100GB.
тестовая сессия
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 столбца, которыеМетрика (размер),Задача,Единица измеренияа такжерезультат.
Мы можем разделить данные в соответствии с Задачей, вы можете получить несколько наборов результатов, таких как:
- данные макроса без задачи
- групповые данные с добавлением индекса
- данные группы index-stats
- данные группы node-stats
- данные группы фраз
- ...
Разные группы означают применение ElasticSearch в разных сценариях, поэтому при сравнении нужно смотреть данные по группам. Данные внутри группы намного проще.За исключением макроданных, данные в других группах в основном представляют собой шаблон, который можно разделить на следующие 14 групп данных.
- Min/Median/Max: минимальная пропускная способность, медианная пропускная способность и максимальная пропускная способность, протестированные в этой группе, единицами измерения являются операции/с, чем больше, тем лучше.
- 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
Вот пример моих тестовых данных.
В соответствии с различными операциями, соответствующими каждой группе данных, мы можем разделить данные на несколько групп, Здесь я разделяю данные по цвету на базовой основе, сверху вниз:
- индексное время
- Индексное время дроссельной заслонки
- Время слияния
- Комбинированное время регулирования
- время обновления
- Обновить время
Во-первых, давайте посмотрим на индексное время первой группы.Имеется четыре индикатора индексного времени:
- Совокупное время индексации основных сегментов: Совокупное время индексирования основных сегментов.
- Совокупное время индексирования по основным сегментам: Совокупное время индексирования по сегментам.
- Совокупное время регулирования индексации основных сегментов: Совокупное время регулирования индексирования основных сегментов.
- Совокупное время регулирования индексации по основным сегментам: Совокупное время индексирования регулирования по сегментам.
Эти четыре показателя описывают время индексации, необходимое 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 |
В этой группе результатов испытанийTencent Cloud требует больше всего вычислительного времени, Alibaba Cloud может повысить производительность примерно на 16% на основе Tencent, а UCloud может повысить производительность на 24% на основе Tencent Cloud..
Во время теста фактическое время теста будет отличаться из-за таких факторов, как производительность машины. Среди этих трех групп самым удивительным является Alibaba Cloud, потому что время его тестирования достигает 6 часов. В то время как UCloud и Tencent Cloud составляют около 3 часов и 4 часов соответственно, в реальных условиях тестирования все еще существует большой разрыв. Если вы хотите воспроизвести соответствующий эксперимент, рекомендуется делать это утром, чтобы результаты теста были еще в дневное время.
Далее смотрим данные времени слияния
- Совокупное время регулирования слияния основных сегментов: Совокупное время регулирования слияния основных сегментов.
- Минимальное совокупное время регулирования слияния для основных сегментов: совокупное время регулирования слияния основных сегментов.
- Среднее совокупное время регулирования слияния для основных сегментов: совокупное среднее время регулирования слияния основных сегментов.
- Максимальное совокупное время регулирования слияния для основных сегментов: максимальное совокупное время регулирования основных сегментов.
Результаты группы времени слияния аналогичны группам времени индекса, за исключением времени слияния измеренных данных. Как и в случае с индексом, чем короче время, тем лучше, и чем больше количество слияний, тем лучше.
| 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 |
В этой группе результатов испытанийTencent Cloud требует больше всего вычислительного времени.Alibaba Cloud может повысить производительность примерно на 9% на основе Tencent, а UCloud может повысить производительность на 30-40% на основе Tencent Cloud.
Несколько других групп подобных данных здесь приводиться не будут, Вы можете скачать окончательные данные статьи для анализа, оценки и выводов.
Как понять тестовые данные проекта, возвращаемые 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 |
В этой группе результатов испытанийAli Cloud, Tencent Cloud, 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 | % |
В этой группе результатов испытанийУ Alibaba Cloud, Tencent Cloud и 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, вы можете загрузить сжатый пакет, соответствующий данным дорожки, на локальный сервер, вы можете решить, какую дорожку использовать для имитации реальной сцены в соответствии с вашим фактическим использованием.
Суммировать
Прежде чем ваш бизнес начнет использовать ElasticSearch, вы можете, как и я, использовать Rally для проведения стресс-тестов на альтернативных кластерах ElasticSearch и проанализировать результаты стресс-тестов, чтобы получить четкие рекомендации по выбору. Например, в моем тесте UCloud явно лучше двух других, и это более экономичный выбор. Конечно, это стресс-тест в экспериментальной среде, и более научно проводить тесты на основе конкретных бизнес-сценариев для выбора моделей.Однако я надеюсь, что метод стресс-теста можно будет использовать для ознакомления, и добро пожаловать. чтобы следить за ходом тестирования. Дайте мне обратную связь.
приложение
Тестовые данные, используемые в этой статье, можно найти вссылка на скачиваниеоказаться.