Настройка нагрузочного тестирования инфраструктуры через Gatling

Настройка нагрузочного тестирования инфраструктуры через Gatling

Представьте: вы запускаете новый релиз, а через час продакшн ложится под пиковой нагрузкой. Команда пытается воспроизвести сценарий вручную — безрезультатно. Знакомо? Именно для таких ситуаций нужно нагрузочное тестирование на Gatling. Мы настраиваем его под вашу инфраструктуру: описываем stateful-сценарии на Scala, интегрируем в CI/CD, получаем HTML-отчёты с перцентилями. Наш опыт — 10+ лет, более 50 проектов в e-commerce, fintech и SaaS. Один кейс: после настройки Gatling клиент сократил время поиска узких мест на 40% и предотвратил два серьёзных инцидента.

Почему Gatling, а не JMeter или k6

JMeter хорош для быстрого старта с GUI, но XML-конфиги на 500 строк для сложных сценариев превращаются в кошмар ревью. k6 — отличный вариант для разработчиков, пишущих тесты на JavaScript. Gatling выигрывает там, где нужны: сложные stateful-сценарии с корреляцией токенов, высокая конкурентность (десятки тысяч виртуальных пользователей на одной машине благодаря Akka/Netty), встроенные HTML-отчёты с перцентилями и детализацией по каждому запросу. Переход на Gatling сокращает время поиска узких мест на 30–50% по сравнению с JMeter-скриптами. А по производительности Gatling работает в 2-3 раза быстрее при одинаковой нагрузке — это подтверждают бенчмарки.

Как Gatling решает проблему корреляции токенов

На одном проекте с e-commerce платформой тестировали поток «поиск → карточка товара → добавление в корзину → оформление заказа». JMeter не справлялся с корреляцией CSRF-токенов между запросами. Gatling решил это через css("#csrf-token").ofType[String].saveAs("csrfToken") и header("X-CSRF-Token", "#{csrfToken}") — всё в рамках одного сценария.

Структура проекта и сценарий

Стандартная структура Gatling-проекта:

gatling-tests/
  ├── src/test/scala/
  │   ├── simulations/
  │   │   └── CheckoutSimulation.scala
  │   └── config/
  │       └── Config.scala
  ├── src/test/resources/
  │   ├── gatling.conf
  │   ├── feeders/
  │   │   └── users.csv
  │   └── bodies/
  │       └── checkout-payload.json
  └── pom.xml # или build.sbt

Базовый сценарий с реалистичным профилем нагрузки:

class CheckoutSimulation extends Simulation {
  val httpProtocol = http
    .baseUrl("https://api.example.com")
    .acceptHeader("application/json")
    .contentTypeHeader("application/json")
    .shareConnections

  val userFeeder = csv("feeders/users.csv").circular

  val checkoutScenario = scenario("Checkout Flow")
    .feed(userFeeder)
    .exec(
      http("Login")
        .post("/auth/login")
        .body(StringBody("""{"email":"#{email}","password":"#{password}"}"""))
        .check(jsonPath("$.token").saveAs("authToken"))
        .check(status.is(200))
    )
    .pause(1, 3)
    .exec(
      http("Add to Cart")
        .post("/cart/items")
        .header("Authorization", "Bearer #{authToken}")
        .body(ElFileBody("bodies/checkout-payload.json"))
        .check(status.is(201))
        .check(jsonPath("$.cartId").saveAs("cartId"))
    )
    .pause(2, 5)
    .exec(
      http("Checkout")
        .post("/orders")
        .header("Authorization", "Bearer #{authToken}")
        .body(StringBody("""{"cartId":"#{cartId}","payment":"card"}"""))
        .check(status.in(200, 201))
    )

  setUp(
    checkoutScenario.inject(
      rampUsersPerSec(1).to(50).during(2.minutes),
      constantUsersPerSec(50).during(5.minutes),
      rampUsersPerSec(50).to(1).during(1.minute)
    )
  ).protocols(httpProtocol)
    .assertions(
      global.responseTime.percentile(95).lt(500),
      global.failedRequests.percent.lt(1)
    )
}

Профиль rampUsersPerSec → constantUsersPerSec → rampDown — стандартный для production-like тестирования. Ступенчатый «столб» нагрузки даёт время на прогрев JVM-приложений и кэша БД, что ближе к реальному трафику, чем мгновенный spike.

Какие метрики гарантируют стабильность продакшена?

HTML-отчёт Gatling — один из лучших в индустрии. Ключевые метрики: p50/p75/p95/p99 latency по каждому запросу, throughput (req/s), активные пользователи во времени. Паттерн, который встречается регулярно: p50 = 120ms, p99 = 4500ms. Это «длинный хвост» — медленные запросы, которые invisible в среднем значении. Обычно причина: database connection pool exhaustion, N+1 query под нагрузкой, GC pause в JVM-приложении.

Если responseTime.percentile(95) растёт линейно с ростом нагрузки — узкое место в приложении. Если растёт скачкообразно при определённом RPS — упираетесь в конкретный ресурс: CPU, I/O, connection pool.

Интеграция в CI/CD и инфраструктура запуска

Для запуска из GitLab CI с публикацией отчётов:

# .gitlab-ci.yml
load-test:
  stage: performance
  image: gatling/gatling:3.10.3
  script:
    - gatling.sh -sf src/test/scala -rf target/gatling -s simulations.CheckoutSimulation
  artifacts:
    paths:
      - target/gatling/
    reports:
      performance:
        - target/gatling/**/simulation.log
  only:
    - schedules # запуск по расписанию, не на каждый коммит

В GitHub Actions конфигурация аналогична: используем action gatling/gatling-action или кастомный Docker-образ. Важно: не запускайте нагрузочные тесты на каждый коммит — это перегружает pipeline и искажает результаты. Оптимально — по расписанию или перед релизом.

Анализ результатов и типичные находки

Отчёт Gatling позволяет быстро выявить аномалии. Например, если p95 растёт плавно — проблема в масштабировании приложения. Если же при определённом RPS происходит резкий скачок — ищите исчерпание пула соединений или GC. Наши инженеры гарантируют, что после настройки Gatling вы получите чёткий список узких мест с рекомендациями. Экономия от предотвращения одного инцидента может превышать стоимость всей настройки в десятки раз.

Что входит в настройку

Настройка Gatling для вашего проекта включает: разработку сценариев под реальные user flows (на основе access logs или аналитики), конфигурацию фидеров данных, интеграцию в CI/CD pipeline, настройку assertions и алертов при деградации, первый прогон с анализом результатов и рекомендациями. Свяжитесь с нами для аудита вашей инфраструктуры — получите готовый план нагрузочного тестирования. Получите консультацию по настройке нагрузочного тестирования — это поможет избежать простоев и сэкономить бюджет.

Стоимость рассчитывается индивидуально после аудита инфраструктуры и требований к тестированию.