k6 vs JMeter vs Gatling vs Locust: какой инструмент нагрузочного тестирования выбрать в 2026

«Какой инструмент для нагрузочного лучше?» — вопрос, на который нет ответа без контекста. k6, JMeter, Gatling и Locust решают одну задачу — сгенерировать нагрузку и измерить, как система себя ведёт, — но по-разному, и «лучший» зависит от твоего стека, команды и того, что именно ты грузишь.

Сразу главное: выбор инструмента вторичен. Большинство провальных нагрузочных тестов проваливаются не из-за тулы, а из-за того, что грузили не то, не на том окружении и смотрели не на те метрики. Сначала разберёмся с этим, потом — с инструментами.

Сначала не инструмент, а сценарий

Прежде чем открывать любой из четырёх, ответь на три вопроса:

Что за нагрузка? Разные типы проверяют разное: load (ожидаемый трафик — держит ли SLA), stress (наращиваем до отказа — где потолок и как падает), spike (резкий всплеск — переживает ли распродажу/рассылку), soak/endurance (часы под нагрузкой — течёт ли память, пухнет ли пул соединений), breakpoint (плавный рост до первой деградации).
Какие метрики = успех? Не «среднее время ответа». Среднее прячет хвост. Смотри перцентили p95/p99, error rate, throughput (RPS), и сравнивай с заранее заданным SLO («p95 < 400 мс при 1000 RPS, ошибок < 0.1%»). Без порога тест — просто красивые графики.
Прод-подобное ли окружение? Нагрузка на стенд в 10 раз слабее прода не говорит ничего. Как и нагрузка на прод без плана отката.

Если на эти три вопроса нет ответа — инструмент не спасёт.

k6 — code-first, заточен под CI

Движок на Go, сценарии пишешь на JavaScript/TypeScript. Стал де-факто дефолтом для «инженерного» нагрузочного: тест — это код в репозитории, а не проект в GUI.

Плюсы: лёгкий и быстрый (Go под капотом, высокий RPS с одной машины), нативно дружит с CI, есть thresholds — встроенные пороги, которые роняют билд при нарушении SLO. Хорошие метрики из коробки, экспорт в Grafana/Prometheus, облако Grafana Cloud k6 для распределённого прогона и хранения истории.
Минусы: JS-рантайм не полноценный Node (свои модули), по умолчанию не браузерный — грузит на уровне протокола HTTP, а не реальный рендеринг (есть отдельный browser-модуль на Chromium, но это не основной кейс). Меньше «экзотических» протоколов, чем у JMeter.
Кому: командам с HTTP/REST/gRPC API, которые хотят тесты рядом с кодом и в пайплайне на каждый PR.

JMeter — ветеран на все протоколы

Apache JMeter — старейший из четвёрки. GUI для сборки сценариев, план теста хранится в XML, огромная экосистема плагинов.

Плюсы: протоколов больше всех — HTTP, JDBC (базы), JMS/очереди, FTP, SMTP, gRPC, WebSocket (через плагины). Не нужно уметь программировать, чтобы собрать базовый сценарий. Распределённый режим (master/workers), гора материалов и ответов за 20 лет.
Минусы: тяжёлый; GUI только для отладки — прогон нагрузки запускают в non-GUI режиме, иначе сам JMeter станет бутылочным горлышком. XML-план плохо ложится в git (ревью диффа — боль). Классическая модель поток-на-виртуального-пользователя упирается в память и потолок потоков на высоких VU.
Кому: legacy-стек, много не-HTTP протоколов (JDBC/JMS), команда без разработчиков, нужен GUI.

Gatling — высокий RPS и code-as-test на JVM

Gatling — сценарии на Scala или Java DSL (в новых версиях — и JavaScript/TypeScript). Асинхронный движок (на базе Akka/Netty) не держит поток на каждого пользователя, поэтому выжимает много нагрузки с одной машины.

Плюсы: высокая производительность за счёт неблокирующей модели, выразительный DSL «как сценарий», из коробки красивые HTML-отчёты с перцентилями и графиками, тест = код в git.
Минусы: порог входа выше (Scala пугает; Java/JS-DSL сгладили это). Распределённый прогон и корпоративные фичи — в платном Gatling Enterprise. Меньше готовых протоколов, чем у JMeter.
Кому: JVM-командам, которым нужен высокий RPS с ограниченного числа генераторов и code-as-test без тяжести JMeter.

Locust — нагрузка кодом на Python

Locust — сценарии на Python, поведение пользователя описываешь обычным кодом. Распределённый по дизайну (master + workers), есть веб-дашборд в реальном времени.

Плюсы: максимально гибкий — любой протокол или кастомная логика пишутся на Python (не привязан к HTTP). Низкий порог для Python-команд, легко переиспользовать свои библиотеки, живой веб-UI по ходу прогона.
Минусы: чистый Python-воркер упирается в GIL и даёт меньше нагрузки на ядро, чем k6/Gatling — компенсируется числом воркеров (можно поднять gevent/FastHttpUser для скорости). Отчёты скромнее, историю/тренды надо строить самому.
Кому: Python-командам и сценариям со сложной кастомной логикой, где важнее гибкость кода, чем максимальный RPS с одной ноды.

Матрица выбора

Язык сценариев: k6 — JS/TS; JMeter — GUI/XML (Groovy для логики); Gatling — Scala/Java/JS; Locust — Python.
Модель нагрузки: JMeter — поток на пользователя (тяжелее); k6/Gatling — асинхронная (высокий RPS с ноды); Locust — greenlet’ы, но GIL.
Протоколы: JMeter — максимум; k6 — HTTP/gRPC/WebSocket; Gatling — HTTP/gRPC/и др.; Locust — что напишешь на Python.
CI-first: k6 и Gatling — да (код + пороги); Locust — да (headless-режим); JMeter — да, но через non-GUI и XML.
Отчёты/тренды: Gatling — отличные из коробки; k6 — через Grafana/Cloud; JMeter — плагины/Listener’ы; Locust — базовые, тренды сам.
Распределённость: JMeter/Locust — из коробки; Gatling — в Enterprise; k6 — через k6 Cloud/оркестрацию.
Порог входа: Locust/k6 — низкий; JMeter — средний (GUI); Gatling — выше (JVM/Scala).

Как выбрать под задачу

HTTP/REST API + хочешь тесты в CI на каждый PR → k6. Дефолт 2026 для инженерных команд, пороги роняют билд при нарушении SLO.
Legacy, много протоколов (JDBC, JMS, gRPC), команда без кода, нужен GUI → JMeter. Швейцарский нож, живёт везде.
Нужен высокий RPS с ограниченного числа генераторов, команда на JVM, code-as-test → Gatling. Асинхронный движок + отчёты из коробки.
Python-команда или сложная кастомная логика поведения → Locust. Пишешь нагрузку как обычный код.

Все четыре — зрелые и бесплатные в основе (Gatling и k6 монетизируют облако/enterprise). Ошибиться с выбором в рамках этого списка сложно: гораздо чаще губит не тула, а то, что ниже.

Грабли, которые важнее выбора инструмента

Тест не на прод-подобном окружении. Половина мощностей, другой инстанс БД, отсутствующий кэш — и цифры не значат ничего.
Один генератор нагрузки — бутылочное горлышко в самом тесте. Упёрся в CPU/сеть клиента раньше, чем сервер вспотел. Мониторь и генератор тоже; масштабируй воркерами.
Смотришь среднее вместо перцентилей. Среднее 200 мс при p99 4 сек — это боль для каждого сотого пользователя. Всегда p95/p99.
Нет мониторинга сервера. Нагрузка без метрик CPU/памяти/GC/пула соединений/БД показывает «медленно», но не «почему». Смотри обе стороны.
Coordinated omission. Многие инструменты недооценивают задержки, если не учитывать пропущенные из-за лагов запросы — держи фиксированную скорость поступления (open model), а не «жди ответ, потом шли следующий».
Нет think-time и прогрева. Реальные юзеры не долбят без пауз; холодный старт/JIT/кэш искажают первые минуты — добавь ramp-up и разумные паузы.
Не уникальные тестовые данные. Один и тот же id/юзер → всё летит из кэша, тест врёт в плюс. Параметризуй данные.
Нет baseline и тренда. Один прогон = точка без смысла. Нужна база («было p95 380 мс») и прогон на релизах, чтобы ловить регресс производительности.

Чек-лист

Определены тип нагрузки (load/stress/spike/soak) и цель.
Есть измеримый SLO (p95/p99, error rate, RPS), а не «посмотрим».
Окружение прод-подобное; план на прод — с откатом.
Инструмент выбран под стек и протоколы, не по хайпу.
Генератор нагрузки мониторится и при нужде масштабируется.
Метрики — перцентили, не среднее; смотрим и сервер (CPU/mem/GC/DB).
Учтён coordinated omission (open model / фиксированная скорость).
Есть ramp-up, think-time, уникальные тест-данные.
Есть baseline и прогон на релизах для ловли регресса.
Пороги (thresholds) роняют билд при нарушении SLO.

Инструмент нагрузочного — это на 20% про выбор из k6/JMeter/Gatling/Locust и на 80% про то, что ты грузишь, на чём и что измеряешь. Выбери подходящий под стек — и вложись в остальное.