Комментарии 8
Спасибо за статью.
Удивительно простая метрика. Это разовый ручной анализ или такая метрика собирается постоянно?
Если постоянно, то правильно ли я понял, что раз Grafana, а не Kibana даёт метрику, то вероятно базой метрик тут выступает не ElasticSearch, а что-то ещё, возможно, Graphite / InfluxDB. А раз так, и выше упомянута Heka, то Heka анализирует логи балансировщика нагрузки, складывает их в Graphite / InfluxDB, а далее Grafana визуализирует метрику (Количество * Длительность)?
Почему спрашиваю. Потому что в рассказах коллег из других компаний они используют для анализа времени обработки запросов например такую связку: HP Real User Monitoring + ClickHouse + Grafana. И говорят, что такая связка работает на предельных оборотах. Какие технологии у Вас справляются с анализом пользовательской активности?
С помощью Grafana мы проанализировали пользовательскую интенсивность в приложении за несколько месяцев. За единицу измерения решили взять суммарное процессорное время выполнения запросов, то есть учитывались количество запросов и время их выполнения.
Удивительно простая метрика. Это разовый ручной анализ или такая метрика собирается постоянно?
Если постоянно, то правильно ли я понял, что раз Grafana, а не Kibana даёт метрику, то вероятно базой метрик тут выступает не ElasticSearch, а что-то ещё, возможно, Graphite / InfluxDB. А раз так, и выше упомянута Heka, то Heka анализирует логи балансировщика нагрузки, складывает их в Graphite / InfluxDB, а далее Grafana визуализирует метрику (Количество * Длительность)?
Почему спрашиваю. Потому что в рассказах коллег из других компаний они используют для анализа времени обработки запросов например такую связку: HP Real User Monitoring + ClickHouse + Grafana. И говорят, что такая связка работает на предельных оборотах. Какие технологии у Вас справляются с анализом пользовательской активности?
Нашел ответ на свой вопрос в более ранней публикации: Работа с потоком логов в реальном времени с помощью Heka. Опыт Яндекс.Денег. Heka отправляет данные в ElasticSearch в реальном времени
И более простой вопрос. Про Concurrency Thread Group, который приведён на картинке. Таймеры используются вместе с этой катушкой? Throughput Shaping Timer можно использовать при наличии в сценарии транзакций, группирующих запросы?
Не использовал такую связку ранее, так как не мог понять, как считать для неё параметры. Инструкция по Throughput Shaping Timer огромна. И смущает, что надо задать RPS. В текущей статье описывается пример, когда нет транзакций, только запросы. Поэтому счётчик RPS будет точным. А у меня в работе много транзакций, и предполагаю транзакции дадут лишние (но на деле не выполняющиеся) запросы, завысив RPS. Поэтому и решил, что мне Throughput Shaping Timer не подойдёт.
И поэтому использую надёжную простую связку Utlimate Thread Group + Test Action + Constant Throughput Timer / Precise Throughput Timer. Опираясь на шаг для транзакций.
Или тут открытая модель нагрузки. Без таймеров, только количество потоков через Concurrency Thread Group. И все расчёты будут точны, если опираться на медианное значение времени отклика на проде?
Не использовал такую связку ранее, так как не мог понять, как считать для неё параметры. Инструкция по Throughput Shaping Timer огромна. И смущает, что надо задать RPS. В текущей статье описывается пример, когда нет транзакций, только запросы. Поэтому счётчик RPS будет точным. А у меня в работе много транзакций, и предполагаю транзакции дадут лишние (но на деле не выполняющиеся) запросы, завысив RPS. Поэтому и решил, что мне Throughput Shaping Timer не подойдёт.
И поэтому использую надёжную простую связку Utlimate Thread Group + Test Action + Constant Throughput Timer / Precise Throughput Timer. Опираясь на шаг для транзакций.
Или тут открытая модель нагрузки. Без таймеров, только количество потоков через Concurrency Thread Group. И все расчёты будут точны, если опираться на медианное значение времени отклика на проде?
Здравствуйте.
Зачастую мы не используем таймеры в катушках. В примере используется только Concurrency Thread Group. Throughput Shaping Timer мы используем только в тех случаях, когда необходимо ограничить нагрузку на приложение. А расчеты необходимы для первоначального подбора параметров, которые при первых запусках корректируются, если это необходимо. Все данные в момент экспериментов мониторятся онлайн, чтобы оперативно реагировать на ситуацию. Наша задача состояла в достижении максимальной производительности приложения до наступления «разладки», поэтому Throughput Shaping Timer в данном случае не подходит.
У нас тоже есть сценарии, где запросы объединяются в transaction controller. Именно по метрикам transaction controller определяется производительность и время ответа транзакции.
Зачастую мы не используем таймеры в катушках. В примере используется только Concurrency Thread Group. Throughput Shaping Timer мы используем только в тех случаях, когда необходимо ограничить нагрузку на приложение. А расчеты необходимы для первоначального подбора параметров, которые при первых запусках корректируются, если это необходимо. Все данные в момент экспериментов мониторятся онлайн, чтобы оперативно реагировать на ситуацию. Наша задача состояла в достижении максимальной производительности приложения до наступления «разладки», поэтому Throughput Shaping Timer в данном случае не подходит.
У нас тоже есть сценарии, где запросы объединяются в transaction controller. Именно по метрикам transaction controller определяется производительность и время ответа транзакции.
Проводятся ли у вас тесты производительности при внедрении новых приложений? В чем корень возникновения ситуации?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление мощностями: в поисках идеального баланса