🔥 Куда я пропал на 2 недели, и причём тут 70 VU

🔥 Куда я пропал на 2 недели, и причём тут 70 VU?

Привет! 👋

Если вы заметили, что блог притих, - это не лень, а полное погружение в боевые задачи. Последние две недели я с головой ушёл в новую, захватывающую тему: Нагрузочное тестирование.

Это был невероятный челлендж!

Когда прилетает такая задача, интерес перевешивает всё, и ты не замечаешь, как после рабочего дня продолжаешь разбираться.

Неделя 1️⃣: Постановка задачи. Борьба за информацию и базовый анализ

Цель: в преддверии акции 11.11 необходимо было проверить как складская система(WMS) будет справляться с повышенной нагрузкой. Предполагалась что количество заказов будет выше почти в два раза чем в обычные дни.

Здесь надо было нагрузить наш основной процесс, чтобы понять будет ли деградация и на сколько будут расти задержки. Тут же, конечно, столкнулись с двумя ключевыми проблемами:

1. Не так давно был изменен один из этапов процесса и мы его не успели ещё автоматизировать. Процесс не простой и с "пол пинка" не автоматизируешь.

2. Вторая проблема это генерация "живых" заказов. Так как у нас нет отдельного стенда под нагрузку, грузить надо было на тестовом стенде, где обычно проводим регресс. Максимально близок по своему состоянию к продакшну. Со всеми интеграциями. Поэтому просто лить синтетику было нельзя, так как почти на каждом шаге данные синхронизируются с различными системами. И мы просто на первом же шаге упадем с ошибкой.

В итоге мы решили пока нагрузить хотя бы GET-запросы, чтобы понять, где система может "споткнутся" во время чтения данных, обращения к БД.

Я сделал 4 сценария:

- Базовый - имитирующий стандартный рабочий день. Продолжительность 60 минут.

- Пиковый - установил значения ожидаемой пиковой нагрузки +10% сверху. Продолжительность 60 минут.

- Стресс - короткий на 20 минут тест с резким повышением нагрузки, +30% к пику.

- Продолжительный(Soak) - 6 часовой тест с базовой нагрузкой.

Инсайт 1: Ценность простого теста.

Мы увидели, что WMS в целом хорошо справляется с нагрузкой в ключевых точках. И при тестировании не наблюдалось деградации. Плюс смогли понять средний RPS нашей системы. Так же были единичные всплески задержек ряда запросов, которые достигали местами 6 секунд. Причины не ясны. Зафиксировали - будем наблюдать.

Инсайт 2: Прозрачность критериев

Какие метрики брать и какие значения использовать для критериев приемки? Пожалуй это самая сложная часть нагрузочного тестирования. Далеко не всегда в документации прописаны метрики, например, самый важный в нашем случае RPS(Requests Per Second) - запросов в секунду. Пришлось для первого раза брать значение "на глаз" и с текущих метрик с прода.

Главный вывод: составлять и уточнять метрики и их значения заранее. Уделить этому самое сильное внимание.

Нагрузку провел на выходных 2.11. В понедельник выложил интерпретацию результатов в конфлюенс.

Думал на этом пока всё. И после акции продолжим работы.

Но...

Продолжение будет в другом посте.