JMeter, k6 и Gatling: чем они правда различаются

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

Полезнее сравнивать то, что нельзя обойти деньгами на железо.

Что подтверждается репозиторием

Данные ниже сняты с GitHub 7 августа 2026 года.

	JMeter	k6	Gatling
Язык движка	Java	Go	Scala
Сценарии	GUI и XML, Groovy через JSR223	JavaScript	DSL на Scala, Java или Kotlin
Лицензия	Apache-2.0	AGPL-3.0	Apache-2.0
Звёзд	9 492	31 197	6 944
Последний коммит	20 июля 2026	6 августа 2026	27 июля 2026

Все три живы: ни один не архивирован, у всех коммиты свежее месяца — так что аргумент «этот уже мёртвый» здесь не работает ни против кого.

Лицензия важнее скорости

Строчка, которую пропускают почти все обзоры: k6 распространяется под AGPL-3.0, а не под MIT или Apache.

AGPL требует раскрывать исходный код производной работы, если она доступна пользователям по сети. Для команды, которая просто запускает k6 в своём CI, это ничего не меняет. А для компании, которая обернула k6 в собственную платформу нагрузочного тестирования и продаёт к ней доступ снаружи, — меняет всё.

JMeter и Gatling под Apache-2.0 такого требования не предъявляют. Если вы строите продукт вокруг генератора, это первое, что надо выяснить, — и последнее, о чём вспоминают.

Язык сценария выбирает не тестировщик

Второй фактор, который решает на практике, звучит скучно: сценарии придётся сопровождать, а сопровождает их тот, кто на этом языке пишет.

Команда, где нагрузку делают Java-разработчики, естественно берёт Gatling с его DSL на Java или Kotlin. Там сценарий проходит обычный код-ревью, и никто не спрашивает, как отладить XML. Команда фронтендеров так же естественно берёт k6, потому что JavaScript у них родной.

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

Как тест попадает в пайплайн

Здесь между инструментами настоящая разница, а не вкусовая.

У k6 критерий приёмки живёт прямо в сценарии, и нарушенный порог даёт код возврата 99. Пайплайн краснеет сам, дописывать нечего.

У JMeter и Gatling такого механизма из коробки нет. Отчёт формируется, а решение «прошло или нет» приходится собирать самому: разобрать результаты, сравнить с эталоном, вернуть ненулевой код. Это делается, но это ваш код, который тоже надо сопровождать.

Если нагрузка встраивается в CI, разница ощутима с первого дня.

Чего в таблице нет

Протоколы я в сравнение не выношу намеренно.

Причина в том, что список протоколов у всех троих расширяется плагинами, и честно сравнить «из коробки» против «с плагином» нельзя. У JMeter есть Plugins Manager, у Gatling своя система расширений, у k6 расширения на Go. Заявление «этот умеет gRPC, а тот нет» почти всегда означает лишь то, что автор обзора не поставил плагин.

Что бы выбрал я

Для команды, которая пишет на JVM и хочет нагрузку в код-ревью, Gatling. Для команды, которая встраивает нагрузку в пайплайн и не строит вокруг неё продукт, k6. Для организации, где нагрузочное тестирование ведёт отдельная группа без разработчиков, JMeter.

Возразить тут есть чему. Например, что GUI JMeter развращает и порождает неподдерживаемые планы, которые никто, кроме автора, не откроет. Это правда, и я видел такие планы. Но альтернатива в подобных организациях обычно не «тот же процесс на другом инструменте», а отсутствие нагрузочного тестирования вовсе.