Материалы доклада
Профилирование #JVM в #Kubernetes

https://heisenbug-piter.ru/2021/spb/talks/7xxou7lmwvn6xnfrx4atnd/
Слайды доступны на странице доклада.
Или так: https://polarnik.github.io/JVM-profiling-in-Kubernetes/

В тему доклада было обсуждение в подкасте Битовая каска (29 апр. 2021 г):
Профилирование приложений: https://youtu.be/hUW7-pTOlaI

Всем привет! Есть новости для тех, кто раздумывает посетить конференцию по нагрузке в Москве, 16 сентября этого года.

Начну с хорошей. Для участников сообщества скидка на билеты будет 50%. Надо быть физическим лицом, и ввести промокод
50% от 12 000 = 6 000 рублей за offline билет

Таких промокодов пока 10 только, поэтому если
▫️16 сентября будет свободное время
▫️и будет возможность быть в Москве
▫️и есть 6000 рублей на билет
то пройдите опрос ниже.

В понедельник раздадим промокоды среди тех, что выбрал вариант "Мне будет нужен промокод на скидку"

+1 к дипломатии, +10 к потенциальным участникам
ссылка на голосование:
https://www.tgoop.com/qa_load/55797

Ссылка на саму конфу:
https://perfconf.ru/

Доброе утро! Сегодня и завтра 8-9 июля пройдет PG Day'21 Russia. Участие бесплатное. Начало в 10:00 МСК, трансляцию можно посмотреть на YouTube. Для общения со спикерами и другими участниками подключайтесь к Slack каналу конференции.

Коллеги, предлагаю наш вариант модуля, упрощающего работу со "СЦЕНАРИЯМИ" тестов Jmeter.

Чем он хорош:
При запуске теста достаточно указать параметры ступеней вашего теста в процентах профиля:
- Начни с нагрузки в 100%, потом шагай ступеньками по 10%

А параметры, нужные для подачи нагрузки по ВСЕМ операциям, входящим в сценарий, будут рассчитаны автоматически.
Так как в сценарии обычно много тред-групп (работающих с разной интенсивностью), настройки каждой тред-группы могут отличаться.
С нашим модулем изменять настройки КАЖДОЙ тредгруппы больше не потребуется.


Подробное описание по ссылке:
https://github.com/ganeles/JmeterSmartScenario

@gim6626 написал на Хабре большую статью (почти методичку) о личном опыте и опыте Miro в развитии направления нагрузочного тестирования - https://habr.com/ru/company/miro/blog/573338/. Основное внимание уделено именно общей методологии НТ, а не техническим деталям отдельных инструментов. Статья будет полезна в первую очередь новичкам, так как там пошагово расписаны все этапы от формулировки требований до составления отчёта с приведением конкретных примеров из практики компании, в том числе по автоматизации. Опытным инженерам статья тоже может быть интересна как пример того, как устроено НТ в другой компании.

Материалы доклада
Профилирование #JVM в #Kubernetes

Запись:
https://youtu.be/JzOlHADAnpA
(на качестве 480p картинка не очень хорошая, на остальных настройках хорошая)

Слайды:
https://polarnik.github.io/JVM-profiling-in-Kubernetes/
Для красивого просмотра слайдов нужно скачать и установить шрифт Roboto:
https://fonts.google.com/specimen/Roboto

Описание доклада

В тему доклада было обсуждение в подкасте Битовая каска (29 апр. 2021 г):
Профилирование приложений: https://youtu.be/hUW7-pTOlaI

Программа конференции по тестированию Heisenbug готова!

За три дня вы сможете посмотреть 23 доклада и поучаствовать в 6 воркшопах.
В программе есть доклад о нагрузочном тестировании.

Виктор Ганелес, Кирилл Юрков — «Антипаттерны тестирования производительности»
В тестировании производительности есть свои особенности, которые можно назвать паттернами. Паттерны могут быть очень специфичными для прикладной задачи, а еще их можно перечислять вечно. Именно поэтому авторы расскажут о том, какие бывают антипаттерны и где они таковыми являются, а где нет.

Посмотреть всю программу, и купить билет можно на сайте.

Вы еще успеваете купить Personal Standard билет со скидкой по промокоду qaload2021JRGpc

Коллеги, если кому интересно:
Сегодня и завтра буду рассказывать коллегам про RabbitMQ, приглашаю желающих присоединиться
Время: с 15 до 18

Информация будет довольно базовая:
Содержание первой лекции (https://youtu.be/JhBNvS5iGQU):
Теория:
- Что такое очереди и зачем они нужны
- Возможности RabbitMQ
- Отличия RabbitMQ и Kafka

Практика:
- Установка RabbitMQ (на примере Windows)
- Настройка RabbitMQ
- Настройка разных типов Exchange в RabbitMQ (сортировка приходящих сообщений по очередям)


Содержание второй лекции (https://youtu.be/E2oo4WIjcec)

- Работа с RabbitMQ из Jmeter при помощи плагина:
- - отправка сообщений в разные топики
- - получение сообщений из топиков

- Настройка мониторинга:
- - Ставим InfluxDB и Grafana
- - Мониторим RabbitMQ при помощи Telegraf
- - Настраиваем вывод информации в Grafana

С вопросами по нагрузочному тестирования приглашаю всех в сообщество в телеграме
https://www.tgoop.com/qa_load

Артефакты доступны по ссылке:
https://drive.google.com/drive/folders/1WCRzMJdQIxLCxUJYiRD8DsA0QxwunFuz
Среди артефактов:
- Инструкция по установке RabbitMQ
- Плагины к Jmeter для работы с RabbitMQ
- Пример работы с RabbitMQ из Jmeter
- Чат с обоих лекций

Группа в Telegram, которая использовалась во время лекций:
https://www.tgoop.com/RabbitMQ_Lesson

Запись первой лекции:
https://youtu.be/JhBNvS5iGQU

Запись второй лекции:
https://youtu.be/E2oo4WIjcec

Продолжаем лекцию по RabbitMQ
https://us02web.zoom.us/j/3174456604?pwd=aDMvenZpOFp0YVp3MWNrY2YzNDg5Zz09

Сегодня в программе -
- работа с RabbitMQ из Jmeter
- настройка мониторинга RabbitMQ через Telegraf и InfluxDB

На мой взгляд - ОЧЕНЬ полезный для нашего сообщества доклад о том, как работают блокировки в бд.
В данном случае речь идёт о MS SQL, но, как мне кажется, часть информации применима к большинству SQL-бд.

Преподаватель очень доходчиво рассказывает и показывает. Рекомендую.

https://youtu.be/iGsbXLgZMlo

Нагружаем банки

Доклад с Heisenbug Moscow 2021

Вячеслав Смирнов, ВТБ
Максим Рогожников, Тинькофф
Владимир Ситников, Netcracker

Рассказ, как в разных командах тестируется производительность — что есть общего, какие бывают фишки. Рассмотрены все аспекты — от планирования и профиля нагрузки до отчетов и ответственности за запуски тестов:

▫️Планирование
▫️Профиль нагрузки
▫️Инструменты
▫️Тестовый стенд
▫️Тестовые данные
▫️Тестирование на продуктиве
▫️Виды тестов
▫️CI/CD для нагрузки
▫️Мониторинг
▫️Логи
▫️Отчеты
▫️Кто делает запуски тестов
▫️Кто поддерживает тесты

🎥 видео:
https://youtu.be/129pEryyHQY
🔗 слайды: https://polarnik.github.io/loading-the-banks/

https://www.youtube.com/watch?v=MzROdc1uvFM
О что появилось !

На днях делали ивент про e2e client-side performance testing, в частности как уменьшить себе боль при работе с sitespeed.io и как джиметр может быть полезен для тестирования клаент сайда
Видосик тут https://www.youtube.com/watch?v=zfAn8SnLyv8 🙂

Всем привет)
8 февраля стартует новая группа по нагрузочному тестированию с нуля
Кому интересны детали пишите в личку тут или в линкедине, там можно и скидочку получить)
https://www.linkedin.com/feed/update/urn:li:activity:6891794583588868097/

А кто уже был и понравилось поддержите лайком или комментом, сильно поможете увеличить охват 🙂
Спасибо)

Вот и видео подъехало про #k6 и #gatling https://www.youtube.com/watch?v=YtZbHhG6EXs
Преза и полезные ссылки:https://www.notion.so/DUMP-EKB-2022-4fe0fe70c35c44238687659f81e893ea

Вот Google Chrome имеет встроенные метрики. Часто приложения мобильные кроссплатформенны за счёт того, что они работают в виджете Google Chrome. И все метрики могут уже у вас быть
https://developer.android.com/guide/webapps/managing-webview

Если у вас Unity то метрики производительности тоже будут

Проверьте это - какая технология в основе лежит

Что я дальше делал. Поискал бы общеиспользуемые метрики для конкретной технологии

Названия метрик можно взять в
Руководствах:
https://firebase.google.com/docs/perf-mon/screen-traces?platform=ios
https://developer.android.com/topic/performance/measuring-performance

Google Lighthouse
https://developer.chrome.com/docs/lighthouse/overview/

Page Speed:
https://web.dev/measure/

В информации о форматах файлов:
https://en.wikipedia.org/wiki/JPEG_2000
https://en.wikipedia.org/wiki/WebP
https://en.wikipedia.org/wiki/Category:Portable_Network_Graphics

Например, у вас PNG это изображение не отображается пока оно полностью не загрузится. Ваши пользователи видят, что отображение долгое. Может быть это загрузка долгая. А она долгая потому что nginx который отдает фотографии не настроен - нет заголовков для кеширования
это можно проверить в fiddler, charlesProxy, proxyman

Или он настроен, но CDN для региона Малайзия используется из Ирландии - и причина где-то там

Или Fiddler, Charles покажут что изображение просто огромное - 5 МБайт фото на iPhone 30 c гигакамерой. Тогда придумайте как делать Preview этого фото и как его скачивать - разделите. Или просто пожмите все, как сделали в vk с потерями возможно.

Если все не так. То вам можно профилировать
https://developer.android.com/topic/performance/benchmarking/macrobenchmark-overview
и замерять отрисовку по косвенным признакам - длительности работы Render-потоков. Может будет не точно, но тоже ок
https://developer.android.com/reference/kotlin/androidx/benchmark/macro/FrameTimingMetric
по frameCpuTimeMs

Как настроить поступление данных из jmeter в influxdb?
Тест запускается из jenkins в нескольких экземплярах

1) TAG_AGENT
Если агенты запускаются, как отдельные агенты, без мастер-слейв,
то важно разделить данные с помощью тегов.

Добавить тег с именем агента в результаты, чтобы они не перемешивались.

https://jmeter.apache.org/usermanual/component_reference.html#Backend_Listener

TAG_WhatEverYouWant
You can add as many custom tags as you want. For each of them, create a new line and prefix its name by "TAG_"

Например

TAG_AGENT
Значение - можно такое ${__machineName}
https://jmeter.apache.org/usermanual/functions.html#__machineName

2) TAG_BUILD_ID

И нужен идентификатор запуска из jenkins, чтобы не перемешивать все запуски между собой

https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#using-environment-variables
BUILD_ID
The current build ID, identical to BUILD_NUMBER for builds created in Jenkins versions 1.597+

Например такой тег, тоже добавляется новой строкой в BackendListener:

TAG_BUILD_ID
Значение

${__P(BUILD_ID)}

BUILD_ID прокидывается из переменных окружения в тест JMeter, как property.

3) Параметры Backend Listener

По накоплению метрик перед записью есть пара настроек, они в jmeter.properties

Суть такая - сохранять метрики каждую секунду теста не стоит, будет много метрик.
Оптимально сохранять метрики раз в минуту или раз в 30 сек.

Описал настройки для Backend Listener тут
https://polarnik.github.io/influxdb-bench/#44

https://polarnik.github.io/influxdb-bench/#45

Например тест делает 50 запросов в сек.
Мы хотим отправлять метрики раз в 60 сек.

Значит надо хранить примерно 3000 метрик в очереди
QUEUE_SIZE = 5000 (по умолчанию) - такое значение нас устраивает его хватает

backend_metrics_window_mode=timed 
backend_influxdb.send_interval=60 # было 5
backend_metrics_large_window=5000 # это устраивает нас > 3000

А вот тест делает (с одного агента) уже 200 запросов в сек и мы настраиваем отправку раз в 60 сек.
Значит надо хранить примерно 12000 метрик в очереди перед отправкой.

QUEUE_SIZE = 12000 (увеличиваем)
backend_metrics_window_mode=timed 
backend_influxdb.send_interval=60 # было 5
backend_metrics_large_window=12000 # было 5000

4) Сумма по BUILD_ID = сумма сумм по AGENT

Когда метрики записаны с нескольких одновременно работающих агентов, их надо визуализировать.
Тут только есть тонкость, как суммарные метрики считать:
- суммарная интенсивность работы со всех агентов
- суммарное количество ошибок со всех агентов
- их отношение (суммарный процент ошибок за весь тест)
- суммарное количество потоков

Сначала надо посчитать сумму с группировкой по AGENT, a потом по BUILD_ID.
Считать сумму сразу по BUILD_ID не получится в InfluxDB.

То есть все запросы на сумму будут с подзапросами.
Это третий вариант суммирования, описанный в статье
https://habr.com/ru/company/raiffeisenbank/blog/490764/

тут по моему докладу статью на хабр вкрутили, там как раз про фантастическую сущность PerfOps. буду рад комментариям)
https://habr.com/ru/company/oleg-bunin/blog/682746/

Доклад про Performance as a service в Самокат можно послушать 29 сентября в рамках очередного Samokat_tech meetup. Приходите - буду рад всех видеть. https://www.tgoop.com/samokat_tech/115

Как делать надежные и качественные сервисы?
Об этом инженеры Тинькофф расскажут на митапе 1 декабря в Екатеринбурге. На встрече вместе с участниками обсудят:

— как обеспечивают site reliability в Тинькофф;
— подход Shift left в нагрузочном тестировании;
— проблемы в надежности «железа» и инфраструктуры.

🗓 Митап пройдет 1 декабря в БЦ «Палладиум».
Начало в 19:00. Регистрируйтесь на странице встречи: https://o.tinkoff.ru/nik.meetup.tinkoff
Страница прошедшего мероприятия:
https://meetup.tinkoff.ru/event/its-tinkoff-meetup-nadezhnost-i-kachestvo/