У нашего бизнеса нет денег на нагрузочное тестирование. Мне интересно свой проект написать и поэксперементировать с его архитектурой, поэтому хочется учить что-то, что в мире питона котируется)
Я бы с радостью все пробовала, если бы молодость никогда не заканчивалась)
Если явных фаворитов нет – попробую Locust)
Просто для ORM как бы тоже есть несколько вариантов, но ни разу не видела, чтобы использовали что-то кроме джанги или алхимии, и подумала: может, для нагрузочного тестирования примерно такая же ситуация.
В любом случае спасибо ❤️
Locust — вполне «котируемый» и разумный выбор для Python, особенно если цель — не формально закрыть нагрузочное тестирование на работе, а экспериментировать с архитектурой собственного проекта.
Что сейчас считается современным подходом
Главный тренд — не конкретная утилита, а performance testing as code:
сценарии хранятся рядом с кодом приложения;
тесты запускаются из CI/CD;
задаются автоматические критерии прохождения: например, p95 < 300 мс и ошибок меньше 1%;
моделируется реальный поток запросов, а не просто «запустим 500 потоков»;
результаты сопоставляются с метриками приложения, базы данных и инфраструктуры.
Например, k6 поддерживает пороговые значения, которые завершают тест с ошибкой и подходят для автоматических performance-gates в CI. Он также явно разделяет нагрузку по числу виртуальных пользователей и по интенсивности поступления запросов — open/closed workload models.
Есть ли разница, на чём написано web-приложение
Для обычного HTTP/API-тестирования — практически нет. Генератор нагрузки видит URL, HTTP-запросы, cookies, токены и ответы. Ему безразлично, обслуживает их Django, FastAPI, Spring или Go.
Язык инструмента влияет на другое:
насколько удобно писать сложные пользовательские сценарии;
можно ли переиспользовать Python-библиотеки и вспомогательный код;
сколько запросов способен создать один генератор;
насколько удобно моделировать нужный тип нагрузки;
какие протоколы и интеграции поддерживаются.
Не стоит только слишком тесно связывать тест с внутренностями приложения — например, напрямую импортировать ORM-модели сервера. Нагрузочный тест полезнее держать преимущественно black-box: работать с системой так же, как реальный клиент.
Как выглядят основные варианты
Locust — лучший первый кандидат, когда хочется остаться в Python. Сценарии пишутся обычным Python-кодом, есть web-интерфейс, распределённый запуск master/worker и произвольные формы нагрузки. Встроена поддержка HTTP/HTTPS, а другие протоколы можно подключать через собственные клиенты.
Его важный нюанс: генератор тоже может стать узким местом. Locust использует кооперативную конкурентность, поэтому несовместимая с gevent библиотека способна заблокировать worker. Для высокого RPS существует FastHttpUser, потребляющий существенно меньше CPU, чем стандартный HTTP-клиент Locust.
k6 — очень сильный универсальный вариант, особенно для CI/CD. Движок ориентирован на экономное потребление ресурсов, тесты пишутся на JavaScript/TypeScript, есть thresholds, arrival-rate сценарии и browser API.
Gatling — мощный code-first инструмент, особенно логичный в JVM-мире. Сейчас сценарии можно писать не только на Scala, но и на Java, Kotlin, JavaScript и TypeScript. Он хорошо подчёркивает правильное моделирование открытых и закрытых систем.
JMeter никуда не исчез и остаётся полезным благодаря зрелости, GUI и большому числу поддерживаемых сценариев и протоколов. Но для нового личного проекта его XML/GUI-подход обычно менее приятен, чем Locust или k6.
Что выбрать именно для такого проекта
Я бы выбрал Locust, но изучал бы не только его API, а общие понятия:
baseline, load, stress, spike и soak tests;
open и closed workload models;
throughput, error rate, p50, p95, p99;
saturation — CPU, пул соединений, база, очереди, внешние API;
coordinated omission и ситуации, когда замедлившаяся система искусственно снижает создаваемый тестом RPS.
Хороший учебный проект: Python API + PostgreSQL + Redis, несколько реалистичных Locust-сценариев, затем поочерёдно менять индексы, кэширование, размер connection pool, число workers и архитектуру фоновых задач. Это даст намного больше понимания, чем просто освоение синтаксиса конкретного инструмента.
Так что аналогия с ORM здесь немного другая: единственного доминирующего варианта нет, но внутри Python-экосистемы Locust — наиболее естественный и узнаваемый выбор. А вторым инструментом позже стоит посмотреть k6, чтобы увидеть другой подход к моделированию нагрузки.
Спасибо большое!!!!!! Правда на новой почве стало еще больше вопросов 😅
По поводу black-box:
Насколько плохо импортировать схемы ручек?
С одной стороны: это часть приложения и нигде, по логике, кроме него самого не должна использоваться
Но с другой: схемы ручек относятся к открытому интерфейсу и чем-то приватным особо не является, так почему бы их не импортировать в locust, раз они так доступны и могут помочь валидировать корректность тестов через статический анализатор, как пример?)
Вообще есть ли какие-то хорошие книги по тематике?)