Ответ
Performance тестирование — это тип нефункционального тестирования, который оценивает, как система ведет себя под определенной нагрузкой с точки зрения скорости, стабильности, масштабируемости и использования ресурсов.
Основные виды performance-тестирования:
| Вид тестирования | Цель | Пример сценария |
|---|---|---|
| Нагрузочное (Load Testing) | Проверить поведение под ожидаемой пиковой нагрузкой. | 1000 пользователей одновременно заходят на главную страницу. |
| Стрессовое (Stress Testing) | Найти точку отказа системы, выявить узкие места. | Постепенно увеличивать нагрузку до 5000 пользователей. |
| Тестирование стабильности/надежности (Soak/Endurance) | Обнаружить утечки памяти или проблемы деградации. | Нагрузка в 500 пользователей поддерживается 24 часа. |
| Тестирование масштабируемости (Scalability Testing) | Определить, как система масштабируется с ростом нагрузки. | Увеличение числа серверов для обработки растущего RPS. |
| Спайковое (Spike Testing) | Проверить реакцию на резкие, кратковременные скачки нагрузки. | Рекламная акция вызывает всплеск трафика за 2 минуты. |
Ключевые метрики:
- Время отклика (Response Time):
Среднее,90-й процентиль (p90),Максимальное. - Пропускная способность (Throughput): Запросов в секунду (RPS/QPS), транзакций в секунду (TPS).
- Использование ресурсов: Загрузка CPU, потребление RAM, дисковый I/O, сетевой трафик.
- Количество ошибок: Процент неудачных запросов под нагрузкой.
Типичный стек инструментов:
- JMeter (де-факто стандарт, Java, с GUI).
- k6 (современный, на JavaScript/Go, сценарии пишутся в коде).
- Gatling (высокопроизводительный, на Scala, хорошая отчетность).
- Locust (Python-скрипты, распределенная нагрузка).
Почему это важно? Оно предотвращает падение продакшн-систем под реальной нагрузкой, помогает оптимизировать архитектуру и обосновать необходимость в аппаратных ресурсах.
Ответ 18+ 🔞
А, performance-тестирование, говоришь? Ну это когда ты, такой весь из себя, написал свой сервис, он у тебя на локалхосте летает как угорелый, а потом выпускаешь его в мир, и он под первыми же десятью пользователями ложится как ополовиненный, блядь. А ты сидишь и думаешь: "Нахуя я вообще всё это делал?"
Так вот, это и есть проверка, выдержит ли твоё творение реальный мир, или оно — говно собачье.
Основные виды, чтобы ты понимал, с чем имеешь дело:
| Вид тестирования | Суть вопроса | Пример, чтобы было понятно даже мартышке |
|---|---|---|
| Нагрузочное (Load Testing) | Проверим, не обосрётся ли система, когда к ней придут все, кого ты ждёшь. | Тысяча человек одновременно тычут кнопку "Купить" в твоём интернет-магазине. |
| Стрессовое (Stress Testing) | А что будет, если нахуярить пользователей сверх всякой меры? Где именно у нас всё пойдёт по пизде? | Начинаем с тысячи, потом две, потом пять... И смотрим, в какой момент сервер взвоет "мамочка" и выплюнет коды 500. |
| Тестирование стабильности (Soak Testing) | А не сольёт ли наше чудо всю память по капле, если его просто долго мучать? | Держим пятьсот юзеров в онлайне целые сутки. Увидим утечки — будем знать, где копать. |
| Тестирование масштабируемости | А если народу придёт овердохуища, мы просто добавим серверов, или архитектура — говно? | Увеличиваем нагрузку и смотрим, помогает ли горизонтальное масштабирование или мы упёрлись в какую-нибудь общую хуйню вроде базы данных. |
| Спайковое (Spike Testing) | А что если из-за твита какого-нибудь инфлюенсера трафик взлетит в десять раз за минуту? | Резко накидываем нагрузку, как будто объявили раздачу халявных айфонов. Смотрим, как система это переживает (или не переживает). |
На что смотрим, блядь (ключевые метрики):
- Скорость ответа: Не среднюю, ёпта, а 90-й процентиль! Потому что если у девяноста человек всё ок, а десять ждут по десять секунд — это пиздец, а не система.
- Пропускная способность: Сколько запросов в секунду можем проглотить, не подавившись.
- Жрунство ресурсов: Процессор не должен пылать как адское пламя, а память — не должна утекать в никуда.
- Ошибки: Если под нагрузкой каждая десятая операция — ошибка, то это не нагрузочное тестирование, а тестирование терпения пользователя, и они его быстро проебут.
Чем всё это делают?
- JMeter — старый, добрый, как дедовский мотоцикл. Громоздкий, но свой в доску. Все его знают.
- k6 — модный, молодёжный. Сценарии на JS пишешь, всё чётко и быстро.
- Gatling — для тех, кто хочет крутые отчёты и высокую производительность. Немного специфичный.
- Locust — для питонистов. Написал скрипт на Python и пошёл нагружать.
А нахуя это всё? Затем, сука, чтобы в три часа ночи тебе не позвонил начальник с криком "ВСЁ УПАЛО, НАРОД КУПИТЬ НЕ МОЖЕТ!", а ты бы мог спокойно ответить: "Расслабься, у нас стресс-тест показал, что система держит впятеро больше, это просто хостинг лег". И пойти спать дальше. Вот для этого.