Что такое нагрузочное тестирование (Load Testing)?

А, ну вот, смотри, сейчас я тебе объясню, что такое нагрузочное тестирование, но без этих занудных учебников. Представь, что твой сайт — это кабак в пятницу вечером. Функциональное тестирование — это проверить, есть ли пиво в холодильнике и открывается ли дверь. А нагрузочное — это когда в этот кабак вваливается толпа из двухсот мудаков, которые все одновременно орут: «ДВЕ ПИВЫ, БЛЯДЬ! И ЧИПСЫ!». И ты смотришь, не развалится ли твой бар, не сломается ли касса и не начнёт ли бармен бить посудой о голову посетителей.

Основные цели, или «Чего мы хотим увидеть перед тем, как всё накроется медным тазом»:

1. Пропускная способность: Сколько этих самых «пив» твой бар может впихнуть в орущую толпу за секунду, прежде чем холодильник захлопнется.
2. Время отклика: Как быстро бармен доносит кружку от крана до стойки. Если он начинает нести её со скоростью похоронного марша — это пиздец.
3. Поиск узких мест: Кто конкретно всех тормозит? То ли процессор (бармен) тупит, то ли память (полки) забита, то ли диск (холодильник) не успевает открываться, то ли сетевая карта (посудомойка) захлебнулась.
4. Стабильность: А не сядет ли весь этот цирк на бровь через час, когда самые упоротые посетители начнут требовать уже пятую кружку и петь песни?

Как мы это устраиваем, или «План по заварушке»:

1. Планирование: Решаем, кого и сколько звать. «Окей, через 5 минут у нас тут будет 1000 виртуальных алкашей, которые будут пытаться залогиниться и купить что-нибудь».
2. Создание скриптов: Берём инструмент вроде JMeter (это как пульт управления этой толпой) и пишем сценарий: «Заходим на сайт, тыкаем сюда, потом сюда, орем вот такой запрос».
3. Запуск теста: Жмём кнопку «Пуск» и наблюдаем, как наш виртуальный кабак начинает ебать мозг нашему реальному серверу.
4. Мониторинг: В это время мы, как параноики, смотрим на кучу графиков: процессор, память, сеть, база данных — всё должно быть под колпаком.
5. Анализ результатов: После того как дым рассеялся, смотрим отчёт и думаем: «Ну что, выдержали? Или, как обычно, всё легло на 150-м пользователе, потому что забыли про индексы в базе?».

На что смотрим, или «Цифры, от которых волосы дыбом»:

• Throughput (Пропускная способность): Сколько успешных «Дай пива!» (запросов) пролетает в секунду.
• Response Time (Время отклика): Не среднее, блядь, оно лукавое! Смотрим на 95-й процентиль. Если 95% запросов летают за 200 мс, а остальные 5% — за 5 секунд, то эти 5% пользователей уже успели послать тебя нахуй и уйти к конкурентам.
• Error Rate (% ошибок): Сколько процентов запросов кончилось не пивом, а ошибкой «504 Gateway Timeout» или, что хуже, молчанием.
• Utilization (Загрузка ресурсов): CPU не должен быть постоянно на 100%, как у бармена в час пик, иначе он сгорит. Память не должна упереться в потолок и начать свопиться на диск — это смерть.

Вот, смотри, как это примерно в JMeter выглядит, тут всё просто:

Thread Group // Это наша толпа алкашей
├─ Number of Threads (users): 200 // 200 человек
├─ Ramp-up period (seconds): 60  // Они не все сразу вломились, а подтягивались минуту (наращивание нагрузки)
└─ Loop Count: Forever / 100     // И каждый из них будет тыкать кнопку либо вечно, либо 100 раз

  HTTP Request // А это что они делают
  ├─ Server Name: api.myapp.com // Идут в бар под названием api.myapp.com
  ├─ HTTP Request: GET          // И вежливо спрашивают (GET-запрос)
  └─ Path: /api/v1/products     // «Мужик, покажи, что у тебя есть из продуктов!»

Короче, нагрузочное тестирование — это не прихоть, а суровая необходимость. Это когда ты заранее узнаёшь, выдержит ли твой «шикарный» функционал хоть кого-нибудь, кроме тебя и твоего кота. Чтобы потом не было мучительно больно, когда в продакшене на тебя свалится реальный трафик и всё накроется, а ты будешь сидеть и думать: «Ну ёпта, а кто ж знал-то...».