Представьте: ваш сайт работает при 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 в день — не рискуйте.