Налаштування навантажувального тестування інфраструктури через Gatling

Налаштування навантажувального тестування інфраструктури через Gatling

Уявіть: ви запускаєте новий реліз, а через годину продакшен лягає під піковим навантаженням. Команда намагається відтворити сценарій вручну — безрезультатно. Знайомо? Саме для таких ситуацій потрібне навантажувальне тестування на Gatling. Ми налаштовуємо його під вашу інфраструктуру: описуємо stateful-сценарії на Scala, інтегруємо в CI/CD, отримуємо HTML-звіти з перцентилями. Наш досвід — 10+ років, понад 50 проєктів у e-commerce, fintech та SaaS. Компанія має 10+ років досвіду, 50+ успішних проєктів та 5+ років на ринку навантажувального тестування. Один кейс: після налаштування Gatling клієнт скоротив час пошуку вузьких місць на 40% і запобіг двом серйозним інцидентам, що заощадило приблизно $50,000.

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

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

Як 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://jsonplaceholder.typicode.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. Це «довгий хвіст» — повільні запити, які невидимі в середньому значенні. Зазвичай причина: database connection pool exhaustion, N+1 query під навантаженням, GC pause в JVM-додатку.

Якщо responseTime.percentile(95) зростає лінійно зі зростанням навантаження — вузьке місце в додатку. Якщо зростає стрибкоподібно при певному RPS — упираєтеся в конкретний ресурс: CPU, I/O, connection pool.

Як інтегрувати Gatling у 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 ви отримаєте чіткий список вузьких місць із рекомендаціями. Економія від запобігання одного інциденту може становити $50,000+, що в десятки разів перевищує вартість налаштування (від $1,500).

Що входить у налаштування

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

Кроки для налаштування Gatling на вашому проєкті

1. Встановіть Gatling (завантажте архів або використовуйте Docker-образ gatling/gatling).
2. Напишіть сценарій на Scala, описавши ключовий user flow.
3. Налаштуйте фідери даних (CSV, JSON) для реалістичних даних.
4. Налаштуйте assertions для критичних метрик (наприклад, p95 < 500ms).
5. Інтегруйте тест у CI/CD (GitLab CI, GitHub Actions) із запуском за розкладом.
6. Проаналізуйте HTML-звіт і виявіть вузькі місця.

Вартість розраховується індивідуально після аудиту інфраструктури та вимог до тестування.