Когда нагрузочный тест бесполезен (да, так бывает) 😁

Не каждый тест дает правдивые результаты.

Примеры:
--- Тестируете API, но забываете про CDN – в реальности 90% трафика может идти мимо сервера.
--- Нет реалистичных данных – если в БД 10 строк, а в проде – миллионы, запросы будут работать иначе.
--- Игнорируете внешние зависимости – например, платежный шлюз в тестах отвечает мгновенно, а в проде – 2 сек.

Вывод:
Тест должен максимально повторять продакшен – иначе это просто игра с цифрами.

Или вы сразу на проде гоняете? 😁

Как DNS-кеш может сломать тест?
Сценарий:
Запустили тест на 50k RPS — сервер даже не вспотел. Выкатили в прод — всё рухнуло на 10k.

В чём подвох?
Оказалось, на тестовых машинах был настроен локальный DNS-кеш, который моментально резолвил домены. В проде же запросы уходили в медленный корпоративный DNS-сервис с задержкой 200 мс.

Что делать:
___ Эмуляция продакшена:
___ Используйте dnsmasq или аналоги, чтобы добавить реалистичные задержки DNS.
___ В облаке настройте те же DNS-серверы, что и в проде.

Мониторинг:
___ Замеряйте время DNS-резолва в тестах (например, через dnsperf).
___ Включите эти метрики в отчёт.

Лайфхак:
🔑🔑🔑 Если домен резолвится в одном месте, прописывайте его IP напрямую в /etc/hosts — это снимет нагрузку с DNS, но только если это соответствует продакшену.

DNS — это не просто "телефонная книга интернета". Его лаги могут убить производительность, даже если ваш код идеален. 🙃

тут про айтишку и что я обо всем этом думаю)
давайте наберем 5000 к концу года))

@brunovski_v

Пока лето и меньше работы, хочу проводить короткие тренинги по 3-4 часа на разные темы (JMeter, K6, Playwright, тестирование безопасности).
Цену поставлю адекватную за тренинг примнерно 30-50 евро.
За эти 3-4 часа вы можете научиться, например:
- Делать простую нагрузку на веб-сервис
- Узнать основы Javascript
- Написать первые автотесты
- Понять, что такое XSS / SQL инъекция и как их можно находить
- Прокачать SQL Joins
и так далее.
По окончанию каждому буду выдавать именной сертификат (не так важно, но просто приятно) и 1-2 моих курса в записи (пока не решил какие, у меня разные есть, начинаю от JMETER до JSON и тд).

Вам была бы интересна такая затея?
Если да, напишите коммент, чтобы я понимал и если не сложно, поделитесь постом.

Спасибо и хорошего дня.

🚀 Стартует первый групповой тренинг по Postman + AI бот! 🚀
В июле проведу интенсивный тренинг длительностью 4-5 часов, где мы вместе прокачаемся по основам и продвинутым темам:

🔥 Что будем изучать?
REST API и принципы работы
CRUD операции (создание, чтение, обновление, удаление)
Автоматизация тестов в Postman
Окружения и переменные - как удобно управлять тестами
Коллекции для упорядочивания запросов
Mock-серверы - имитация настоящих API
Работа с токенами и авторизацией
+ бонус: поработаем с AI ботом, который поможет тебе в тестировании!

💡 И самое главное - сделаем реальный проект для портфолио и прокачки навыков!

💰 Стоимость:
Первый поток - всего 50 евро!
Со второго потока цена вырастет до 75-100 евро.

👨‍💻 Для кого?
Для любого IT-специалиста, который хочет углубить знания в API и автоматизации, а особенно для QA Engineer-ов!

📩 Если интересно - пиши мне в Telegram 👉 @faroeman, я создам закрытый чат для участников.
PS: нас уже 7 человек!!!

🙏 Буду очень признателен, если поделишься этим постом - возможно, кому-то из твоих знакомых это будет суперполезно!

PS: Напоминаю, что также провожу индивидуальное менторство по автоматизации на JavaScript, Playwright и JMeter - с нуля до профи!

Готов к прокачке? Жду тебя на тренинге! ⚡

Новый набор + первый отзыв!
Объявляю новый набор на групповое обучение на курс JMETER + GRAFANA + INFLUXDB/PROMETHEUS

Мы выпустили первый поток и у нас появился уже первый отзыв (думаю позже ребята еще напишут)

Курс состоит только из живых онлайн уроков, где вы можете сразу же задавать вопросы опытному преподавателю.

В курсе есть домашние задания, которые проверяет ваш ментор и очень много практики.

После окончания курса вы получаете

- Знания, чтобы устроиться на позицию Инженер по нагрузочному тестированию
- Сертификат
- В подарок от меня очень полезный курс (уже в записи) по JMETER + INFLUX + GRAFANA. Это идет каждому участнику в подарок (цена такого курса отдельно 99 евро, но вам он идет как БОНУС).

Пишите за деталями @faroeman

🎉 РАСПРОДАЖА КУРСА JMeter + Grafana + InfluxDB! 🎉

В честь нового учебного года: 39€ !!!!!

99€ ➝ 39€ 💥

(только до 1 сентября включительно)

🔥 Что вас ждет внутри?
✅ 79 уроков
✅ JMeter (61 урок) – от основ до продвинутого уровня
✅ InfluxDB (10 уроков) – бакеты, таски, интеграция
✅ Grafana (8 уроков) – дашборды, метрики, визуализация
✅ Доступ НАВСЕГДА (Google Диск)

🚀 Для кого курс?
🔹 QA-инженеры, которые хотят прокачаться в нагрузочном тестировании
🔹 Разработчики и IT-специалисты, которым нужен JMeter
🔹 Те, кто хочет вырасти в зарплате или найти работу в тестировании

📊 После курса вы сможете:
– Создавать полноценные нагрузочные сценарии
– Собирать метрики в InfluxDB
– Красиво визуализировать результаты в Grafana

💡 Цена — всего 39€ до 1 сентября!
👉 Пишите за подробностями в Telegram: @faroeman

Скидка действует еще 3 дня ребят, потом цена станет 99
Сейчас 39

Налетай, забирай как говорится ))

Пишите @faroeman

Сегодня последний день скидки 🌝

И с понедельника я продолжаю вести канал по нагрузке, подготовил много полезных материалов

Серьезно. Коллеги, давайте начистоту: сколько раз вы видели идеальный»график нагрузки в JMeter - ровненькая полочка из 500 пользователей, которая длится ровно 10 минут.

А потом вы смотрите на мониторинг приложения и видите... дикие скачки потребления CPU, памяти и латенси. Или, что хуже, - ничего не видите, потому что система легла...

Вот в чем подвох: в реальной жизни так не бывает. Пользователи приходят не все разом. Они подключаются, отваливаются, ходят по разным сценариям и создают рваный, случайный профиль нагрузки.

Так почему мы до сих пор тестируем идеализированные сценарии, которые не имеют ничего общего с реальностью?
Тестировать надо очень реалистичные сценании!

Попробуйте в следующий раз накрутить в своем сценарии:
• Пики: Резкий всплеск на 2-3 минуты (скидка появилась!).
• Постепенное нарастание: Имитация утренней посещаемости.
• Постоянные небольшие колебания числа активных пользователей.

Скорее всего, вы найдете баги, которые никогда не ловились на ровном графике. Особенно связанные с очередями, кэшами и пулами соединений.

Так что помните, нагрузка - это не взял и послал 100 юзеров на api, нифига так не работает
НУЖНЫ РЕАЛИСТИЧНЫЕ СЦЕНАРИИ!!! )))

⏱️ Зачем используется ClickHouse в нагрузочном тестировании?
Когда мы запускаем нагрузочные тесты (например, в JMeter или k6), создаётся огромное количество метрик:

отклик каждого запроса,
время ответа,
процент ошибок,
RPS (запросов в секунду),
задержки, 95-й и 99-й перцентили.

Этих данных миллионы, и хранить их в обычной базе бывает неэффективно.

👉 ClickHouse - это колоночная база данных, созданная специально для анализа больших объёмов данных в реальном времени.

В нагрузочном тестировании она используется для:
✅ Быстрого сохранения результатов даже при большом трафике.
✅ Построения красивых дашбордов (например, в Grafana).
✅ Глубокой аналитики - можно смотреть статистику за любой промежуток времени, находить узкие места, сравнивать разные прогоны.

📊 Получается, ClickHouse - это типа сердце аналитики в нагрузочном тестировании. Тесты дают данные, ClickHouse их хранит, а Grafana красиво показывает.

Ну кстати я использовал всегда Influxdb, но это уже совсем другая история

Что выбрать: ClickHouse или InfluxDB?
Часто вижу этот вопрос у тех, кто работает с метриками, логами и вообще с большим количеством данных. На первый взгляд кажется, что это два конкурирующих решения, но у них разная философия и область применения.

InfluxDB изначально создавался как база для временных рядов. То есть это отличный вариант, если у вас данные строго по времени - метрики серверов, сенсоры IoT, данные мониторинга. Она удобна для записи огромного количества точек в секунду и простой аналитики по времени.

ClickHouse - это аналитическая колоночная база. Она гораздо шире по применению: от логов и аналитики до полноценного дата-хранилища. Ее фишка - скорость агрегаций на больших объемах. Сюда можно грузить терабайты данных и строить отчёты, которые в обычной базе просто «лягут».

Если у вас классическая задача мониторинга, где важна простота, готовые клиенты и экосистема (например, интеграция с Telegraf или Grafana), то InfluxDB подойдёт лучше. Если же нужно хранить и обрабатывать тонны данных, гибко агрегировать, строить сложную аналитику -тогда ClickHouse.

В идеале, выбор зависит от того, что именно вы хотите делать: быстро хранить и визуализировать метрики или глубоко копать в большие массивы данных.

Datadog - это платформа для мониторинга и анализа, которая собирает метрики, логи и трассировки в реальном времени.

Что это значит для нагрузочного тестирования?
Когда вы запускаете нагрузку (например, с JMeter или K6), одних только показателей «ответ сервера» или «время отклика» часто недостаточно.

Нужно понимать, почему система замедляется или падает.
✅ Datadog помогает:
- Отслеживать метрики серверов, БД и микросервисов под нагрузкой.
- Смотреть в одном месте, как ведут себя CPU, память, диски, сеть.
- Ловить узкие места (ботлнэки): где именно появляется ботлнек
- Сопоставлять результаты нагрузочного теста с инфраструктурными метриками.

💡 Итог: Datadog делает нагрузочное тестирование осмысленным - без него вы видите только «сломалось/не сломалось», а с ним понимаете почему.

Чем хорош Groovy и почему его лучше знать в связке с JMeter?

Когда вы работаете с JMeter, рано или поздно стандартных элементов становится мало. Настоящая гибкость появляется тогда, когда подключается Groovy.

Groovy - это язык, который отлично встраивается в JMeter. С его помощью можно:
- писать кастомные скрипты для обработки данных;
- динамически подставлять значения в запросы;
- делать проверки и ассерты, выходящие за рамки стандартных возможностей;
- автоматизировать генерацию тестовых данных.

Почему лучше знать хотя бы основы?
Потому что без Groovy вы ограничены только тем, что дает интерфейс JMeter. А с Groovy вы получаете свободу: любую логику можно реализовать напрямую в скриптах.

Для нагрузочного тестировщика это значит одно - вы становитесь более самостоятельным и ценным специалистом. Даже базовые знания Groovy уже позволяют делать проекты гибче и эффективнее.

Так что знать основы будет неплохо, не обязательно быть супер спецом по Груви!

Нужно ли использовать Debug Sampler в JMeter?
Debug Sampler - это специальный элемент в JMeter, который показывает содержимое переменных, properties и контекст теста прямо во время выполнения.

Когда полезен:
- при отладке сложных сценариев с множеством переменных;
- если нужно быстро проверить, подставляется ли корректное значение в параметры запроса;
- для обучения новичков —-сразу видно, что хранится внутри JMeter.

Когда вреден:
- в нагрузочном тестировании на большом числе потоков Debug Sampler сильно замедляет выполнение;
л- ишний вывод может засорять результаты и мешать анализу;
- в продакшн-тестах он не нужен.

Вывод: использовать Debug Sampler стоит только во время настройки и отладки сценариев. Для боевых нагрузочных прогонов его обязательно нужно убирать.

Я постоянно использую Debug Sampler, если я вытаскиваю переменную через Regular Extractor например, тогда мне сразу видно ее содержимое

Распределённое тестирование в нагрузочном тестировании - это подход, при котором нагрузка на систему создаётся не с одного компьютера, а с нескольких, объединённых в сеть.

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

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

Плюсы:
- можно достичь реалистичных нагрузок в сотни тысяч или миллионы пользователей;
- нагрузка распределяется равномерно и не перегружает одно устройство;
- проще моделировать разные сценарии: пользователи из разных регионов, разные каналы связи.

Минусы:
- настройка сложнее, чем у локального теста;
- важна синхронизация времени и стабильность сети;
- при ошибках в конфигурации результаты могут быть искажены.

Итог: распределённое тестирование —-обязательный инструмент, если вы работаете с высоконагруженными системами. Локальные тесты годятся только для отладки сценариев.

Проведем прямой эфир в Facebook? Скажем на следующей неделе. Пообщаемся, поотвечаю на вопросы что думаю про ИТ, найм, будущее в айтишке.

Подписывайтесь на мой профиль основной, там и сделаем.
Расскажу, как действовать сейчас и на что обратить внимание (мое скромное мнение)
https://www.facebook.com/vitali.bru/ - вот ссылка

💡 Почему знание SQL критически важно для Инженера по нагрузочному тестированию?
Нагрузочное тестирование почти всегда связано с базами данных. Даже если система выглядит «легкой», под капотом у неё почти всегда SQL-запросы.

🔑 Основные причины:
- Поиск узких мест
При нагрузке именно запросы к БД становятся бутылочным горлышком. Умение читать SQL и план выполнения запроса помогает понять, почему система «тормозит».

- Оптимизация сценариев теста
Неверно составленные тестовые данные или неоптимальные запросы могут исказить результаты. QA-инженеру важно отличать проблему в коде приложения от проблемы в БД.

- Мониторинг в реальном времени
При тестах нужно смотреть на активные запросы, блокировки, долгие транзакции. Без SQL тут никуда.

- Анализ результатов
После прогона важно понять, что именно нагружалось: таблицы, индексы, соединения. SQL-аналитика помогает объяснить заказчику, где слабое место.

⚡ Итог:
Инженер по нагрузочному тестированию без SQL - как водитель без знания правил дорожного движения. Можно ехать, но риск аварии слишком велик.

Звучит может смешно, но это так и есть.

И да, помните про индексацию, это важно!

Что такое пропускная способность (Throughput) и почему это важно?
📌 Throughput (пропускная способность) - это показатель, который показывает, сколько запросов система обрабатывает за единицу времени (обычно измеряется в requests per second или transactions per second).

🔎 Пример:
Если сервер обрабатывает 500 запросов в секунду, значит его throughput = 500 RPS.

⚡ Почему это важно:
- Понимание реальной мощности системы. Не только «держит ли сервер нагрузку», но и насколько эффективно.
- Сравнение разных конфигураций. Например, изменение количества потоков, оптимизация кода или базы данных.
- Бизнес-метрика. Чем выше throughput, тем больше пользователей система может обслужить без деградации.
- Раннее выявление узких мест. Если throughput перестаёт расти при увеличении нагрузки, значит достигнут предел.

🛠️ На практике:
В JMeter, K6 и других инструментах throughput отображается в отчетах и графиках.
Его часто сравнивают с response time и error rate, чтобы понять, выдерживает ли система нагрузку.

👉 Итог: Throughput - один из ключевых индикаторов в нагрузочном тестировании. Если он падает при росте нагрузки - у вас бутылочное горлышко (боттлнек), которое надо искать и устранять.

Что такое 99-й персентиль в нагрузочном тестировании
Многие думают, что если среднее время отклика = 1 секунда - значит всё хорошо.
Ошибка. Среднее - это иллюзия.

📊 99-й персентиль показывает, сколько запросов хуже, чем у 99% остальных.
Если 99-й персентиль = 3 секунды - значит 1% запросов шли дольше 3 секунд.
Именно эти запросы и убивают UX, мониторинг и прод.
Потому что пользователю всё равно, что у “среднего” всё ок - если у него лично всё зависло.

🧠 Проще говоря:
среднее скрывает проблему,
персентиль показывает реальность,
99-й - это ваш “худший случай”, но в реальной жизни он случается постоянно.

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