Тестирование нагрузки сайтов с помощью wrk2, ab и k6

Если ты хоть раз запускал свой сайт, поднимал сервис на VPS или собирался мигрировать на выделенный сервер, наверняка задумывался: а сколько реально выдержит мой проект, если на него внезапно ломанётся толпа пользователей? Как понять, где узкое место — в коде, в железе, в настройках nginx или в сети? Здесь на помощь приходят инструменты для нагрузочного тестирования, такие как wrk2, ab (ApacheBench) и k6. В этом посте разложу по полочкам, как быстро и без лишнего геморроя начать тестировать свой сайт, почему это важно, и как не наступить на типовые грабли. Всё — на примерах и с минимальной теорией, максимумом практики.

Зачем вообще тестировать нагрузку?

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

• Понимаешь, где пределы: сколько запросов в секунду реально держит твой сервер.
• Ловишь узкие места: база данных, сеть, приложение — что тормозит первым?
• Экономишь на ресурсах: не покупаешь лишний VPS или сервер, если твой сайт работает и на маленьком инстансе.
• Готовишься к пикам: акции, рассылки, DDoS — заранее знаешь, выдержит ли твой стек.

В чём суть проблемы?

Многие думают: “Запущу сайт — если что, потом разберусь с производительностью”. На практике это приводит к тому, что в самый неожиданный момент (например, после публикации на Хабре или Telegram-канале) сайт умирает, а ты судорожно ищешь, где заказать новый VPS или выделенный сервер (VPS, dedicated — пригодится на будущее). Но если заранее погонять тесты wrk2, ab или k6 — можно избежать этих фейлов.

Как работают wrk2, ab и k6?

Все три — это генераторы HTTP-запросов, которые эмулируют нагрузку на твой сайт. Но у каждого свой стиль и нюансы:

• ab (ApacheBench): олдскульный, но до сих пор рабочий инструмент. Прост, как гвоздь, но не умеет сложные сценарии.
• wrk2: форк популярного wrk, рассчитан на более точное поддержание RPS (requests per second), идеально для бенчмаркинга API.
• k6: современный, скриптуемый, умеет распределённые тесты, интеграцию с CI/CD, поддерживает сложные сценарии.

Давай разберёмся чуть глубже.

ab (ApacheBench): Алгоритм и структура

• Запускает заданное число запросов к URL.
• Может держать несколько одновременных соединений (concurrent).
• Печатает статистику: среднее время ответа, процентиль, количество ошибок.

Минус: не умеет сценарии, не поддерживает WebSockets, HTTP/2, сложные заголовки.

wrk2: Алгоритм и структура

• Мультипоточный, написан на C, очень быстрый.
• Может поддерживать заданный RPS (в отличие от wrk, который просто “жмёт в пол”).
• Позволяет писать Lua-скрипты для кастомных сценариев.

Минус: сложнее, чем ab, требует компиляции на некоторых системах.

k6: Алгоритм и структура

• Пишешь сценарий на JavaScript (ES6), описываешь логику запросов.
• Можешь задавать сложные сценарии, авторизацию, работу с куками, переменными.
• Умеет распределённое тестирование, интеграцию с CI, экспорт в Grafana/InfluxDB.

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

Как быстро и просто всё настроить?

ab: Быстрый старт

На большинстве Linux-серверов ab уже есть, если установлен apache2-utils. Если нет — ставим:

sudo apt install apache2-utils

Запускаем тест на 1000 запросов по 10 параллельно:

ab -n 1000 -c 10 https://example.com/

Параметры:

• -n — всего запросов
• -c — одновременных соединений

Для POST-запроса:

ab -n 500 -c 5 -p postdata.txt -T 'application/json' https://example.com/api/endpoint

wrk2: Быстрый старт

На Ubuntu проще всего собрать из исходников:


sudo apt-get install build-essential libssl-dev git
git clone https://github.com/giltene/wrk2.git
cd wrk2 && make


Запускаем тест на 1000 запросов в секунду, 2 потока, 10 соединений, 30 секунд:


./wrk -t2 -c10 -d30s -R1000 https://example.com/


• -t — потоки
• -c — соединения
• -d — длительность
• -R — целевой RPS

Для сложных сценариев — используем Lua-скрипты (см. официальный репозиторий wrk2).

k6: Быстрый старт

Устанавливаем на Ubuntu:


sudo apt install gnupg ca-certificates
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61
echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt update
sudo apt install k6


Пишем простой скрипт test.js:


import http from 'k6/http';
import { sleep } from 'k6';
export default function () {
http.get('https://example.com/');
sleep(1);
}


Запускаем, например, 10 пользователей, 30 секунд:


k6 run --vus 10 --duration 30s test.js


Всё, тест пошёл!

Сравнение инструментов: плюсы и минусы

Реальные примеры и кейсы

Положительный кейс: API выдержал акцию

Один e-commerce проект заранее прогнал wrk2 с реальными сценариями (авторизация, покупка). После этого оптимизировали кэширование и nginx, и сайт спокойно пережил флешмоб с 5000 RPS. Итог: ни одной жалобы на “зависание”.

Отрицательный кейс: не протестировали — упали

Другой проект (новостной портал) перед запуском не тестировал нагрузку. После публикации в СМИ сайт лег через 2 минуты, потому что база не выдержала лавины SELECT. ab бы помог выявить это за 10 минут.

Нетипичные сценарии

• Тестирование REST API с авторизацией: k6 — лучший выбор, потому что можно описать логин, работу с токенами.
• Быстрый smoke-тест: ab — за минуту получаешь картину производительности.
• Тестирование на Docker-контейнере: wrk2 легко запускается внутри контейнера, главное — не упереться в лимит CPU.

Ошибки новичков и мифы

• “ab покажет реальную нагрузку” — нет, ab не умеет HTTP/2, не поддерживает сложные сценарии. Для современных SPA и API лучше wrk2 или k6.
• “Можно тестировать с локального ноутбука” — если у тебя сервер на другом конце мира, сеть может стать узким местом. Тестируй с того же дата-центра или VPS.
• “Если выдержал 1000 RPS — всё ок” — важно не только средний RPS, но и процентиль (p95, p99), ошибки, лаги.
• “wrk2 — это просто wrk” — нет, wrk2 поддерживает стабильный RPS, а wrk просто “жмёт в пол”, что не всегда отражает реальную нагрузку.
• “k6 — только для DevOps” — на самом деле, любой админ или разработчик может быстро освоить базовые сценарии.

Похожие решения и альтернативы

• Vegeta — генератор нагрузочного тестирования, похож на wrk2, но с конфигами.
• Locust — нагрузочное тестирование на Python, с веб-интерфейсом.
• Gatling — мощный инструмент для сложных сценариев, но требует JVM.

Статистика: кто быстрее?

На практике (из реальных тестов):

• wrk2 — самый быстрый, способен выдавать десятки тысяч RPS даже на среднем сервере.
• ab — упирается в 2-3 тысячи RPS, дальше начинает тормозить сам.
• k6 — средний по скорости, но выигрывает за счёт гибкости и отчётности.

Интересный факт: wrk2 и k6 умеют экспортировать результаты в Prometheus/Grafana для красивых дашбордов.

Нестандартные способы использования

• Проверка работы балансировщика: запускаешь wrk2 с разных VPS — видишь, как балансируются запросы.
• Тестирование failover: во время теста отключаешь один инстанс — смотришь, как быстро переключается трафик.
• Проверка лимитов firewall: ab или wrk2 покажут, когда твой сервер начнёт дропать соединения.
• k6 для тестирования WebSockets (экспериментально): можно писать кастомные модули, если нужен нестандартный протокол.

Автоматизация и новые возможности

• Встраивай k6 в CI/CD: каждый pull request — автоматический прогон теста, падение производительности — сигнал тревоги.
• Скриптуй wrk2 с Lua: можно генерировать случайные данные, тестировать разные сценарии входа/выхода.
• ab легко использовать в bash-скриптах для быстрой проверки после деплоя.
• k6 поддерживает cloud-режим (k6 Cloud) — можно гонять тесты из облака, если свой сервер слабоват.

Выводы и рекомендации

Если тебе нужен быстрый smoke-тест после деплоя — ab подойдёт идеально. Для точного бенчмарка API и поиска узких мест — wrk2 (особенно если хочется поддерживать стабильный RPS). Если же нужно тестировать сложные сценарии, авторизацию, разные типы запросов — k6 вне конкуренции. Не ленись тестировать на том же железе, где будет жить твой проект — если нужен новый VPS или выделенный сервер, смело смотри VPS или dedicated под свои задачи.

И помни: нагрузочное тестирование — это не разовая акция, а регулярная практика. Новая версия сайта, смена конфигурации nginx, обновление PHP — всё это повод прогнать wrk2, ab или k6. Так ты всегда будешь знать, на что способен твой проект, и не окажешься в ситуации, когда “всё легло, а я не знаю почему”.

Официальные ресурсы для изучения:

• wrk2 на GitHub
• Документация ApacheBench
• Документация k6

Пробуй, экспериментируй, автоматизируй — и пусть твой сервер всегда держит удар!