📢 QA — Load & Performance


Kanal geosi va tili: Rossiya, Ruscha


Избранные материалы о тестировании производительности.
Чат и источник тем: @qa_load

Связанные каналы

Kanal geosi va tili
Rossiya, Ruscha
Statistika
Postlar filtri


Оживлю немного канал заметкой о том, как можно сымитировать подачу нагрузки с разных IP-адресов для JMeter и не только. Тут речь про HTTP

Далее копия сообщения 'https://t.me/qa_load/96296/125780' rel='nofollow'>https://t.me/qa_load/96296/125780

А есть ли в системе балансировщик нагрузки или proxy, который и принимает подключения от клиентов? Nginx, haproxy, ...

Если балансировщик/прокси есть, то за ним один backend-сервер или несколько?

Если несколько серверов на стороне сервера приложений, то балансировщик как выполняет балансировку - по ip-address (реальному адресу или заголовку X-Forwarded-For и/или X-Real-IP), по sticky session (cookie), просто рандомом (round robin)

Если выполняет по ip-address (или по X-Forwarded-For заголовку от клиента с адресом), то есть ли ограничения на подключения от балансировщика до одного сервера приложений? Они меньше чем 5000 подключений?

Если ограничения меньше 5000 подключений, то будет возможность просто их увеличить, не навредив серверу?
Было 50 подключений к серверу, а все остальные ждали в очереди в течение 60 секунд, а теперь будет 5000.
Или увеличить таймаут, что может навредить самому тесту (тест будет не тестировать, а ждать)
Было 50 подключений к серверу, а все остальные ждали в очереди в течение 60 секунд, а теперь будут ждать 600 секунд.

Если простые правки настроек не подходят, то будет ли возможность добавить в конфигурацию балансировщика адреса нагрузочной станции (одной), как proxy-сервер верхнего уровня, чтобы эта нагрузочная станция (Apache.JMeter) сама присылала в заголовках запроса заголовки X-Forwarded-For и X-Real-IP с разными ip-адресами (один адрес на каждый сценарий, не на каждый отдельный запрос), а балансировщик доверял этим заголовкам?

Вот так выполняется настройка для nginx
http://nginx.org/en/docs/http/ngx_http_realip_module.html
https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/
в настройку
set_real_ip_from
сервера nginx добавляется ip-адрес нагрузочной станции с Apache.JMeter и nginx начинает думать, что Apache.JMeter это не клиент, а тоже балансировщик, вышестоящий балансировщик, через который приходят запросы реальных клиентов
set_real_ip_from 192.168.0.100;
set_real_ip_from 192.168.0.0/24;
set_real_ip_from ::1;
set_real_ip_from 127.0.0.1;


Для haProxy
https://www.haproxy.com/documentation/haproxy-configuration-tutorials/client-ip-preservation/add-x-forward-for-header/
option forwardfor


Также настройки для работы с внешними прокси есть и в самих серверах приложений. Но такие настройки нужны для других security-фильтров. Если бы такие настройки срабатывали, то был бы ответ не Connection Timeout, а HTTP Code 429. Добавлю их, так как немного связано с этой же темой

Для Python и Symfony
https://symfony.com/doc/2.2/components/http_foundation/trusting_proxies.html
Request::setTrustedProxies(array('192.168.0.100', '192.168.0.0/24', '::1', '127.0.0.1'));

В Scala/Java и Play Framework
https://www.playframework.com/documentation/2.7.x/HTTPServer
play.http.forwarded.trustedProxies=["192.168.0.100", "192.168.0.0/24", "::1", "127.0.0.1"]

В Java Spring Boot + Tomcat
https://docs.spring.io/spring-boot/docs/2.0.0.RELEASE/reference/html/howto-security.html#howto-enable-https
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/RemoteIpValve.html
server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto
server.tomcat.internalProxies="192\.168\.0\.100"
By default, 10/8, 192.168/16, 169.254/16, 127/8, 100.64/10, 172.16/12, and ::1 are allowed.
У параметра internalProxies приоритет выше, чем у trustedProxies:
https://github.com/apache/tomcat/blob/10.0.x/java/org/apache/catalina/filters/RemoteIpFilter.java#L800-L832
Надо разбираться, как работает только internalProxies, без trustedProxies и их комбинация


А заголовки
X-Forwarded-For
X-Real-IP
можно добавить через HTTP Header Manager в JMeter
значения можно делать, например, такие
44.77.111.${__jexl3( ${__threadNum} % 200 )}


счетчики производительности с серверов тоже дадим в формате 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 и пошел

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


У нас в команде результаты тестов производительности сохраняются в Allure. В yaml-файле заданы лимиты. И после теста отельная утилита проверяет соответствие результатов теста лимитам из yaml-файла. Статусы сохраняется в Allure TestOps, как тесты

Такие тесты (yaml-файл с лимитами) заданы в декларативном виде

Сегодня обсуждали фичу, что надо заводить баги по части таких тестов и делать тестам Mute, пока баг не исправлен. Звучало так, что нужно усложнить интеграцию

Сделал такое с JUnit5 и Allure библиотеками. Как эксперимент. В этом случае тест производительности уже задан не в декларативном виде, а кодом. В нем есть механизм Mute, ссылки на Issue. Коллеги имеют опыт работы с такими тестами. Их понятно как отлаживать и писать. Мне кажется, что сложнее не стало

В таким подходе тест на k6 не является тестом — это пререквизит, в ходе которого формируется файл с метриками. А потом уже тест-тест загружает этот файл и применяет Assertion-ы к значениям метрик

Использовал: k6, gson, assertj, junit5, Allure TestOps


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






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


Вячеслав Смирнов dan repost
Вот 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




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

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






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

Доклад с 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, приглашаю желающих присоединиться
Время: с 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.me/qa_load

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

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

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

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


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

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

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

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

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

20 ta oxirgi post ko‘rsatilgan.