Ответ
Нагрузочное тестирование — это тип нефункционального тестирования, целью которого является оценка поведения системы под заданной ожидаемой или пиковой нагрузкой.
Основные цели:
- Определить пропускную способность и время отклика приложения.
- Оценить стабильность и отказоустойчивость под нагрузкой.
- Выявить узкие места в производительности (баттлнеки).
Ключевые метрики:
- Время отклика (Response Time)
- Количество запросов в секунду (RPS — Requests Per Second)
- Процент ошибок (Error Rate)
- Использование ресурсов: ЦПУ, память, диск, сеть.
Пример сценария для JMeter (концептуально):
Thread Group: 500 виртуальных пользователей
├── Ramp-Up Period: 120 секунд (плавный выход на полную нагрузку)
├── Loop Count: 50 итераций на пользователя
└── HTTP Request: GET /api/productsОсновные виды нагрузочного тестирования:
- Load Test: Проверка под планируемой нагрузкой.
- Stress Test: Нагрузка за пределами нормальных условий для поиска точки отказа.
- Soak/Endurance Test: Длительная нагрузка для выявления утечек памяти.
- Spike Test: Резкие, кратковременные скачки нагрузки.
Ответ 18+ 🔞
А, слушай, про нагрузочное тестирование! Ну, это когда ты берешь свою систему, которая вроде бы работает, и начинаешь её ебашить, как последнюю суку, чтобы понять, когда она скажет «всё, пиздец, я больше не могу».
Если по-умному, то это не про то, работает ли кнопка «купить», а про то, не сдохнет ли всё, когда на эту кнопку нажмут одновременно пять тысяч охуевших от скидок пользователей.
Зачем это вообще нужно, блядь?
- Узнать, сколько запросов в секунду твоё творение может проглотить, не подавившись, и как быстро оно потом отплюётся ответом.
- Посмотреть, не развалится ли оно нахуй под нагрузкой или будет героически держаться.
- Найти эти ебучие узкие места — баттлнеки, блядь! — где всё тормозит: то ли база данных, то ли какой-нибудь кривой микросервис.
Что смотрим, пока ебем систему?
- Время отклика — сколько ждать, пока страница откроется. Если больше трёх секунд, пользователь уже мысленно посылает тебя нахуй.
- Запросов в секунду (RPS) — сколько таких «посылов нахуй» система может обработать.
- Процент ошибок — если он больше нуля, уже плохо. Если за 5%, это пиздец, Карл.
- Жрёт ли всё ресурсы — процессор не должен плавиться, память не должна течь, как решето.
Вот, смотри, как это примерно в JMeter выглядит, концептуально:
Thread Group: 500 виртуальных пользователей (это 500 ебланов, которые тупо кликают)
├── Ramp-Up Period: 120 секунд (плавно наращиваем толпу, а не все сразу, как на распродаже)
├── Loop Count: 50 итераций на пользователя (каждый еблан тыкает 50 раз)
└── HTTP Request: GET /api/products (и все они лезут за одним и тем же товаром, идиоты)А виды тестов, они разные, как и способы ебли:
- Load Test: Это как планируемый наплыв народу в магазин в субботу. Проверяем, выдержит ли.
- Stress Test: А это когда мы зовём на эту субботнюю распродажу ещё и армию гоблинов с соседнего района. Нагружаем за пределы нормы, чтобы найти точку, где касса говорит «ой, всё» и накрывается медным тазом.
- Soak/Endurance Test: Длительная, нудная ебля. Оставляем систему под нагрузкой на часы или даже сутки. Цель — поймать утечку памяти, которая проявится только через шесть часов, этакая хитрая жопа.
- Spike Test: Резкий, неожиданный пиздец. С сервера упала нагрузка, все спокойно, и тут БАЦ — DDoS-атака или внезапная новость в твиттере. Смотрим, как система переживает такой пиздюль.
Короче, смысл в том, чтобы найти все слабые места до того, как это сделают живые пользователи. Иначе будет не нагрузочное тестирование, а пост-мортем с разбором полётов на тему «какого хуя всё легло».