Уявіть: ваш сайт працює при 100 відвідувачах, але при 1000 — падає. 50% користувачів йдуть, якщо сторінка завантажується довше 3 секунд. Для e-commerce це втрати до $10 000 на годину простою. Ми — команда інженерів з 10-річним досвідом навантажувального тестування. Розробляємо навантажувальні тести на Locust, щоб виявити вузькі місця до того, як вони вплинуть на бізнес. Наші сценарії імітують реальну поведінку користувачів: авторизація, перегляд товарів, оформлення замовлень. Запускаємо тести в CI/CD — ви дізнаєтесь про проблеми на етапі розробки, а не після деплою. За нашими плечима понад 100 успішних проєктів для e-commerce, SaaS та медіа. Гарантуємо, що після наших тестів ваш сайт витримає будь-яке навантаження.
Згідно з документацією Locust, "Locust is an open-source load testing tool written in Python". Це пояснює його гнучкість: сценарії пишуться на Python, що дозволяє реалізувати будь-яку логіку — від простих GET-запитів до складних потоків авторизації з токенами.
Як ми будуємо навантажувальні тести на Locust?
Порівняння Locust з JMeter
Locust використовує Python — це дає гнучкість у написанні складної логіки (наприклад, авторизація за токеном, генерація динамічних даних). JMeter використовує XML, що менш читабельно. Locust легко масштабується: додайте 10 машин — отримаєте 100 000 користувачів. За нашими тестами, Locust у 3 рази швидше створює навантаження на тому ж залізі.
| Інструмент | Мова сценаріїв | Масштабованість | Веб-інтерфейс |
|---|---|---|---|
| Locust | Python | Висока | Є |
| JMeter | XML | Середня | Є |
| k6 | JavaScript | Висока | Немає |
Чому варто обрати Locust?
Основні переваги: відкритий вихідний код, активна спільнота, підтримка розподіленого режиму та вбудований веб-інтерфейс для моніторингу в реальному часі. Ми використовуємо Locust вже понад 8 років і вважаємо його найкращим вибором для гнучкого навантажувального тестування.
Які сценарії ми пишемо?
Типові сценарії включають:
- Аутентифікація та підтримка сесій
- Пошук за каталогом і фільтрація
- Перегляд детальної картки товару
- Додавання в кошик та оформлення замовлення
- Робота з API для зовнішніх сервісів
Кожен сценарій містить перевірки статусу, часу відповіді та структури даних. Ми використовуємо ваги для симуляції різної частоти операцій.
Приклад базового сценарію
# locustfile.py
from locust import HttpUser, task, between
import random
class WebsiteUser(HttpUser):
wait_time = between(1, 3)
def on_start(self):
self.client.post("/api/auth/login", json={
"email": f"user{random.randint(1,1000)}@test.com",
"password": "testpassword"
})
@task(3)
def browse_products(self):
self.client.get(f"/api/products?page={random.randint(1,10)}")
@task(2)
def view_product(self):
self.client.get(f"/api/products/{random.randint(1,500)}")
@task(1)
def create_order(self):
self.client.post("/api/orders", json={
"product_id": random.randint(1,100),
"quantity": random.randint(1,3)
})
Цей код — основа тесту. Додаємо метрики та пороги спрацювання.
Метрики та перевірки
from locust import events
from locust.runners import MasterRunner
@events.request.add_listener
def on_request(request_type, name, response_time, response_length, response,
context, exception, start_time, url, **kwargs):
if exception:
print(f"Request failed: {name} - {exception}")
elif response_time > 2000:
print(f"Slow request: {name} - {response_time}ms")
@events.quitting.add_listener
def assert_stats(environment, **kwargs):
stats = environment.runner.stats
total = stats.total
if total.fail_ratio > 0.01:
print(f"FAIL: Error rate {total.fail_ratio:.2%} > 1%")
environment.process_exit_code = 1
if total.avg_response_time > 500:
print(f"FAIL: Avg response time {total.avg_response_time:.0f}ms > 500ms")
environment.process_exit_code = 1
p99 = total.get_response_time_percentile(0.99)
if p99 > 2000:
print(f"FAIL: p99 {p99:.0f}ms > 2000ms")
environment.process_exit_code = 1
Збираємо метрики по кожному запиту та встановлюємо пороги: не більше 1% помилок, середній час до 500 мс, 99-й перцентиль до 2 секунд. Перевищення зупиняє тест з кодом помилки.
Запуск тестів
# Headless режим для CI/CD
locust -f locustfile.py --headless --users 100 --spawn-rate 10 --run-time 5m --host https://staging.example.com --html report.html
# Distributed mode (кілька машин)
# Master
locust -f locustfile.py --master --expect-workers=3
# Workers
locust -f locustfile.py --worker --master-host=192.168.1.100
Веб-інтерфейс доступний на http://localhost:8089 для ручного керування.
Як інтегрувати навантажувальні тести в CI/CD?
GitHub Actions example
- name: Run Locust Load Test
run: |
locust -f locustfile.py --headless --users 50 --spawn-rate 5 --run-time 3m --host ${{ vars.STAGING_URL }} --html load-report.html
continue-on-error: false
- name: Upload Report
uses: actions/upload-artifact@v3
with:
name: load-test-report
path: load-report.html
Тести запускаються автоматично при кожному деплої. Якщо пороги перевищено, пайплайн падає — ви дізнаєтесь про проблему до виходу в прод.
Процес роботи та результати
Етапи роботи
- Аналіз — вивчаємо архітектуру, визначаємо критичні операції, збираємо логи реальних користувачів.
- Проектування — пишемо сценарії з вагами, додаємо перевірки.
- Реалізація — створюємо
locustfile.py, налаштовуємо distributed-режим та CI/CD. - Запуск — виконуємо тести на staging та production.
- Звіт — надаємо графіки навантажувального тестування, перцентилі, рекомендації з оптимізації.
Що входить в результат
| Компонент | Опис |
|---|---|
| Сценарії | 3–5 файлів locustfile.py з різними типами користувачів |
| Конфігурація | Налаштування headless, distributed, CI/CD (GitHub Actions / GitLab CI) |
| Документація | Опис сценаріїв, інструкція з запуску, інтерпретація звіту |
| Підтримка | 30 днів консультацій з оптимізації після здачі |
Строки та вартість
Розробка навантажувальних тестів займає від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Інвестиції окупаються за рахунок запобігання простоям: збитки від одного збою в пік сезону можуть перевищувати $100 000.
Типові помилки при навантажувальному тестуванні
- Однотипні сценарії — всі користувачі роблять те саме, не відображаючи реальну поведінку.
- Відсутність перевірок — тест «проходить» навіть при 50% помилок.
- Запуск тільки на staging — production може поводитись інакше через конфігурацію або навантаження.
- Недостатня кількість машин — один сервер не дасть достатнього навантаження для 10 000 користувачів.
- Ігнорування кешів — тести потрібно проводити на «холодному» кеші.
Детальний приклад налаштування distributed-режиму
У distributed-режимі майстер розподіляє навантаження між воркерами. Використовуйте хмарні машини для масштабування до 100 000 користувачів.Висновок
Навантажувальні тести на Locust допоможуть уникнути простоїв та втрати клієнтів. Оцінимо проєкт за 1 день — зв'яжіться з нами. Отримайте консультацію інженера вже сьогодні. Упущена вигода від не працюючого сайту може становити $50 000 на день — не ризикуйте.