Розробка навантажувальних тестів для сайту (Locust)

Уявіть: ваш сайт працює при 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?

Основні переваги: відкритий вихідний код, активна спільнота, підтримка розподіленого режиму та вбудований веб-інтерфейс для моніторингу в реальному часі. Ми використовуємо 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 

Тести запускаються автоматично при кожному деплої. Якщо пороги перевищено, пайплайн падає — ви дізнаєтесь про проблему до виходу в прод.

Процес роботи та результати

Етапи роботи

1. Аналіз — вивчаємо архітектуру, визначаємо критичні операції, збираємо логи реальних користувачів.
2. Проектування — пишемо сценарії з вагами, додаємо перевірки.
3. Реалізація — створюємо locustfile.py, налаштовуємо distributed-режим та CI/CD.
4. Запуск — виконуємо тести на staging та production.
5. Звіт — надаємо графіки навантажувального тестування, перцентилі, рекомендації з оптимізації.

Що входить в результат

Строки та вартість

Розробка навантажувальних тестів займає від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Інвестиції окупаються за рахунок запобігання простоям: збитки від одного збою в пік сезону можуть перевищувати $100 000.

Типові помилки при навантажувальному тестуванні

• Однотипні сценарії — всі користувачі роблять те саме, не відображаючи реальну поведінку.
• Відсутність перевірок — тест «проходить» навіть при 50% помилок.
• Запуск тільки на staging — production може поводитись інакше через конфігурацію або навантаження.
• Недостатня кількість машин — один сервер не дасть достатнього навантаження для 10 000 користувачів.
• Ігнорування кешів — тести потрібно проводити на «холодному» кеші.

Висновок

Навантажувальні тести на Locust допоможуть уникнути простоїв та втрати клієнтів. Оцінимо проєкт за 1 день — зв'яжіться з нами. Отримайте консультацію інженера вже сьогодні. Упущена вигода від не працюючого сайту може становити $50 000 на день — не ризикуйте.