Size: a a a

QA — Load & Performance

2020 April 21

ВС

Вячеслав Смирнов in QA — Load & Performance
Многим же знаком ElasticSearch, LogStash, ... И известно, что это хранилище кластеризуется, что в него можно логи слать просто текстом.

Приводит это к тому, что туда шлют всё подряд. Сейчас в команде нашей так. А это очень дорогое хранилище, если гигабайт логов отослать в Elastic, он там в 10 превратится после индексации. А если превратить 1 ГБайт логов в статистику, сгруппировать, то уже и InfluxDB и MySQL и даже SQLite - отличным хранилищем станут, 10 КБайт любой переварит
источник

A

Alex in QA — Load & Performance
Вячеслав Смирнов
Apache.JMeter, Gatling, Yandex.Tank, LoadRunner Enterprise поддерживают отправку метрик в InfluxDB. В тестировании производительности нет аналогов InfluxDB.

А этот инструмент размазан аргументами вида - плохо работает с огромными базами данных (250 ГБайт RAM, видимо, не меньший размер базы) и много ошибок, например при работе с Prometeus (приведена ссылка на telegraf, а это отдельный продукт), модуль экспорта новый совсем и сырой, что от него ждать, и вообще это конкурент.

https://github.com/freeseacher/metrics_ru_faq

Думаю это правда. И всё так.

Но моё мнение, что метрик не должно быть под терабайт. Это как надо накопить столько - логи сырым текстом слать?
И знание того, что хранилище не может переварить любые данные заставляет осознанно подходить к хранению, к выбору метрик. Это уже маленький, но залог того, что на метрики будут обращать внимание. Что они будут работать.
Отчасти всё так, но в CK проще делать некоторые вещи для которых придется смотреть ваш доклад про influxDB и фишки с запросами. Я не топлю, просто говорю что вполне удобно использовать и для сборка инфы при нагрузке.
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Alex
Отчасти всё так, но в CK проще делать некоторые вещи для которых придется смотреть ваш доклад про influxDB и фишки с запросами. Я не топлю, просто говорю что вполне удобно использовать и для сборка инфы при нагрузке.
Тоже думаю перейти на ClickHouse. Как хранилище он хорош. Вычислительных модулей у него не очень много, InfluxDB его переигрывает. Но его используют в проектах Machine Lerning, как хранилище, откуда выгружаются метрики, которые просчитываются на Python, C++, ...

И жизнь заставит изучить Prometeus очень глубоко, так как Docker и Kubernetes повсюду уже.
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Но ClickHouse не является пререквизитом для ML
источник

A

Alex in QA — Load & Performance
Стыдно спрашивать, но что подразумевается под
>Вычислительных модулей
?
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Функции имел в виду. Возможно мои сведения уже неактуальны. Но пробовал на нём визуализировать монотонно возрастающие метрики, те которые не RPS, а те которые TotalCount - растут и растут. И не смог
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Фунции Среднее, Сумма, Перцентили, Максимум, Минимум, ... для такого вида данных не подходят
источник

A

Alex in QA — Load & Performance
Я не очень много делал и на influx и на CK, но не сталкивался с такими трудностями. Возможно задач таких не было.
источник

A

Alex in QA — Load & Performance
Прям глобальные проблемы которые были -
агенты не умеют слать данные, пришлось патчить телеграф. +*создание доп колонок должно быть реализовано на клиенте, но это не сложно
нет батчинга встроенного, приходится юзать доп прокси
нет алертинга в графане
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
По рассказам сотрудника Яндекса, там вокруг ClickHouse своя экосистема, самописная, с алертами на всё. Она общая для компании, мощная.

К сожалению детали забыл.

А для метрик конкретный человек использовал Prometeus. Не ClickHouse
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
А те люди, которые по метрикам прогнозируют какая реклама понравится пользователю, с ML прогнозами и найросетями, там ClickHouse в основе.
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
А у меня пока InfluxDB, потому что тестирование производительности это отдельная задача, для неё свои инструменты
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Alex
Прям глобальные проблемы которые были -
агенты не умеют слать данные, пришлось патчить телеграф. +*создание доп колонок должно быть реализовано на клиенте, но это не сложно
нет батчинга встроенного, приходится юзать доп прокси
нет алертинга в графане
Было бы интересно послушать. Можно сделать митап или демонстрацию, как это выглядит
источник

A

Alex in QA — Load & Performance
Ну тут нужно учитывать что я делал это в качестве теста, код и практики не бест, но я не против
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
👍
источник
2020 April 22

АФ

Александр Фролов in QA — Load & Performance
Ребята привет, нужен совет, тесты на производительность на проекте делаем нечасто, по необходимости пользуясь только jmeter и отчеты тож вручную стряпали, но внезапно взяли курс на масштабирование, и клиенты хотят от нас некого решения по тестированию производительности на стороннем сервисе где легкое понятное ui и графики красивые и понятные строятся, чтоб в любое время и они сами могли проверить актуальную производительность на проекте, подскажите в сторону чего, лучше и дешевле думать..
источник

M

Maksimall89 in QA — Load & Performance
Александр Фролов
Ребята привет, нужен совет, тесты на производительность на проекте делаем нечасто, по необходимости пользуясь только jmeter и отчеты тож вручную стряпали, но внезапно взяли курс на масштабирование, и клиенты хотят от нас некого решения по тестированию производительности на стороннем сервисе где легкое понятное ui и графики красивые и понятные строятся, чтоб в любое время и они сами могли проверить актуальную производительность на проекте, подскажите в сторону чего, лучше и дешевле думать..
blazemeter.com - думаю ваш прям варинт, легко будет перенести тесты туда с jmeter
источник

SI

Sergey Ikonnikov in QA — Load & Performance
Александр Фролов
Ребята привет, нужен совет, тесты на производительность на проекте делаем нечасто, по необходимости пользуясь только jmeter и отчеты тож вручную стряпали, но внезапно взяли курс на масштабирование, и клиенты хотят от нас некого решения по тестированию производительности на стороннем сервисе где легкое понятное ui и графики красивые и понятные строятся, чтоб в любое время и они сами могли проверить актуальную производительность на проекте, подскажите в сторону чего, лучше и дешевле думать..
Мониторинг производительности может помочь. Приложение постоянно пишет свои метрики в одну из timeseries баз, из которой эти данные берутся для построения дашборда с метриками в grafana.
Вот пример статьи на эту тему https://m.habr.com/ru/post/336650/
источник

ВС

Вячеслав Смирнов in QA — Load & Performance
Александр Фролов
Ребята привет, нужен совет, тесты на производительность на проекте делаем нечасто, по необходимости пользуясь только jmeter и отчеты тож вручную стряпали, но внезапно взяли курс на масштабирование, и клиенты хотят от нас некого решения по тестированию производительности на стороннем сервисе где легкое понятное ui и графики красивые и понятные строятся, чтоб в любое время и они сами могли проверить актуальную производительность на проекте, подскажите в сторону чего, лучше и дешевле думать..
http://www.redline13.com/

Вот ещё вариант - JMeter в облаке
источник

VK

Vitaliy Kudryashov in QA — Load & Performance
Доброго дня, поделитесь опытом профилирования node js -  есть отдельные докер контейнеры для ui (pm2-runtime) и при использовании SSR периодически получаю задержки 3000+ ms на получение страницы
источник