📢 QA — Load & Performance

счетчики производительности с серверов тоже дадим в формате csv
И если после этого предполагается активная работа с Pandas, и метрик много, то это один сценарий.
Если с Excel, Google Tables, чтобы графики построить, а метрик мало, это второй сценарий.
Если с Excel, Google Tables, чтобы таблички отсортировать просто, то третий.

По каждому пункту можно или потратить N времени на обсуждение и потом M времени на реализацию. Или 0 времени на обсуждение, а потом 10xM на реализацию. И так и так получается не мало.

Стоимость работ я тут опущу, как ведутся переговоры по стоимости на фрилансе, мне просто неведомо. N времени на обсуждение уйдет не просто так, чтобы и стоимость согласовать

https://freelance.habr.com/tasks/514195

Необходимо протестировать веб-портал интернет-магазина.
Нагрузочное тестирование сценария заказа для 10 000 пользователей. Нужен опыт проведения такого тестирования.
Будет нужно распределение нагрузки, разные точки нагрузки (сервера).
Сценарий будет предоставлен, нужно будет записать скрипт, параметризировать, заполнить шаблон отчета который дадим. Тестовые данные мы подготовим, счетчики производительности с серверов тоже дадим в формате csv

———

Зашел как-то разговор, можно ли заниматься нагрузкой, не на основной работе? Мне было сложно оценить, я бы сам не смог спланировать такой график. Половина времени в нагрузке занимает общение. Это очень общительная работа, потому что она нетиповая, нешаблонная. А делать нетиповую работу на условном фрилансе очень сложно

Нашел для примера задачу на тестирование производительности (такая была только одна). На ее примере попробую представить, возможно ли ее сделать.

Необходимо протестировать веб-портал интернет-магазина.
С одной стороны, веб-портал это контентная часть проекта. И в качестве результатов тестирования может понадобится анализ с помощью webpagetest.org, pagespeed, ... И рекомендации, касательно кеширования, оптимизации на стороне верстки или касательно размеров изображений. Без работы с которыми можно и не начинать нагрузку на API-часть. Но может иметься в виду тестирование и API и отдачи статики и самой статики, всего.

Нагрузочное тестирование сценария заказа для 10 000 пользователей.
Если речь про скорость выполнения 10 000 итераций сценария заказа, то задача одна.
Если в сценарии подразумевается и вход, поиск, просмотр каждого товара, работа с корзиной, выход, задача другая. Более сложные сценарии, более сложны в отладке, это как с атомарностью тестов. В плохих случаях, до самого заказа можно не дойти из-за нестабильности предыдущих шагов.
Если тут имеется в виду 10 000 одновременных подключений, и разные другие технические а не бизнесовые характеристики, то задача третья. После такой задачи будет, возможно, обсуждение в чате qa_load, что инструмент {название} не тянет нагрузку, что делать, помогите. И будут ответы, что тут имелось в виду, не 10к подключений, а 10к итераций. 10к итераций за время, которое нужно установить или за определенное время.

Нужен опыт проведения такого тестирования.
Значит, как первый проект такое взять не получится. Это задача для человека с опытом, портфолио.

Будет нужно распределение нагрузки, разные точки нагрузки (сервера).
Если тут емеется в виду, что нагрузка будет подаваться из разных точек, то сделать такой тест будет дорого; если речь про сотни адресов.
Если имеется в виду, что будут нагружены все серверы магазина, а не только какой-то один IP-адрес, то надо будет разобраться с тем, как устроена балансировка нагрузки.

Сценарий будет предоставлен, нужно будет записать скрипт, параметризировать
Это, понятная часть работы. Но она зависит от того, что имеется в виду под
Нагрузочное тестирование сценария заказа для 10 000 пользователей.
и
Тестовые данные мы подготовим
Если имеется в виду, что будут даны 10 000 токенов пользователей, а также будет дана выгрузка названий и идентификаторов товаров, чтобы было проще делать эмуляцию наполнения корзины, то у задачи сложность на меньшее количество времени.
Если будут не токены, а логины и пароли в количестве 10 000 штук, то сложность выше.
Если будут даны, не идентификаторы и названия товаров, а только названия, то еще выше.
Вариантов много

заполнить шаблон отчета который дадим
Лично для меня этот этап всегда долгий. В простом случае - система нагрузку держит, вот ссылки на детали. Но если система нагрузку не держит, то анализ почему, результаты 5-ти, 10-ти итераций, фиксация сделанных оптимизаций, фиксация результатов оптимизаций.

Аудитория была доброжелательная. Я волновался, так как мало готовился. А меня подбадривали - ты что как Гарольд, расслабься, это квартирник. Среди присутствующих не было нагрузочников или они не дали о себе знать при знакомстве, поэтому выбрал желтые стикеры для рассказа, они больше про общие истории

Тестирование, когда на рабочем месте нет интернета, тонкости работы с вложениями почты и флешками.

Работа на субподряде, сочинение отчетов и сделки с совестью

Работа в одиночку и важность поддержки

Нужны ли нагрузочные тесты вообще, и если ли они у кого-то

Что ждет команда от нагрузочника, когда все тормозит, а чего точно не ждет

Что имеет в виду пользователь, когда пишет, что у него что-то тормозит, и как важно уточнить все детали, позвонить, написать, прийти или приехать в гости

Рассказал про необычное тестирование очень асинхронного процесса банковских переводов со счета на счет в другом банке, важность трассировки запросов в таких системах

И что не получал выигрыша, если отдавал приоритет работе и проекту, а не здоровью, семье и делам дома

И послушал истории аудитории, про работу на заводах, согласование 800-т страничных распечаток кода программ и что происходит, когда система держит 50 rps, а должна держать 1000:
Если забыть о проблеме, то ее не существует (с)

Аудитории понравилось, мне тоже. Такой вот был доклад, без единой строчки кода на JMeter, k6, Java, но про нагрузку

Всем привет! После активации функции подчатов в чатике по нагрузке, данный канал был автоматически отвязан от него. И тепепрь он сам по себе. Подумал, что можно его оживить. В канале все еще есть 8 администраторов, 8 людей, которые могут писать что-то интересное

Был в субботу 27 мая на IT-квартирнике в Ереване, вышел на замену человеку, который заболел перед мероприятием. Здоровья этому человеку

Квартирник это такой формат, где может быть несколько ведущих и не очень большая аудитория. Ведущий более подходящее слово, чем спикер. Так как все общаются, аудитория активно участвует и развивает дискуссию на заданную тему.

У меня был день на подготовку, поэтому выбрал тему "Стихийное тестирование производительности", сделал в miro.com один слайд в формате квартирника, сайт unsplash.com помог с подборкой фонов, добавил на слайд заметок с историями под разную аудиторию. Добавил пару ссылок и QR-кодов на форму обратной связи да слайды через qrcoder.ru и пошел

Ссылка на слайд вот тут

Как делать надежные и качественные сервисы?
Об этом инженеры Тинькофф расскажут на митапе 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/

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

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

Как настроить поступление данных из 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/

Вот 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

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

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

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

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

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

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

Доклад с Heisenbug Moscow 2021

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

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

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

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

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

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

https://youtu.be/iGsbXLgZMlo

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

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

Коллеги, если кому интересно:
Сегодня и завтра буду рассказывать коллегам про 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://t.center/qa_load

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

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

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

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