📢 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 и пошел Ссылка слайд вот тут

У нас в команде результаты тестов производительности сохраняются в 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

Доклад про Performance as a service в Самокат можно послушать 29 сентября в рамках очередного Samokat_tech meetup. Приходите - буду рад всех видеть. https://t.me/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 = 1200 (увеличиваем)
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