Ответ
Тестирование производительности — это тип нефункционального тестирования, оценивающий скорость, отзывчивость, стабильность, масштабируемость и потребление ресурсов системы под определенной нагрузкой.
| Основные виды тестирования производительности: | Вид тестирования | Цель |
|---|---|---|
| Нагрузочное (Load Testing) | Проверить поведение системы под ожидаемой пиковой нагрузкой. | |
| Стрессовое (Stress Testing) | Найти точку отказа системы, постепенно увеличивая нагрузку за пределы нормы. | |
| Тестирование стабильности/на выносливость (Soak/Endurance Testing) | Выявить утечки памяти или проблемы деградации при длительной (многочасовой) работе под нагрузкой. | |
| Спайковое (Spike Testing) | Проверить реакцию на резкие, кратковременные скачки нагрузки. | |
| Тестирование масштабируемости (Scalability Testing) | Определить, как система справляется с ростом нагрузки путем добавления ресурсов (вертикальное/горизонтальное масштабирование). |
Что является объектом проверки (метрики):
- Время отклика (Response Time) ключевых операций.
- Пропускная способность (Throughput), например, запросов в секунду.
- Утилизация ресурсов: загрузка ЦП, память, диск, сеть.
- Количество ошибок под нагрузкой.
Пример конфигурации сценария в JMeter:
Thread Group:
Number of Threads (users): 100
Ramp-Up Period: 30 seconds // 100 пользователей за 30 сек.
Loop Count: Forever
HTTP Request:
Server Name: api.example.com
Path: /v1/orders
Method: GETЦель: выявить узкие места (баттлнеки) в архитектуре (БД, кэш, внешние API) и убедиться, что система соответствует требованиям к производительности.
Ответ 18+ 🔞
А, ну вот, классика жанра, блядь! Тестирование производительности! Это когда ты смотришь, как твоё творение, эта мартышлюшка-система, не развалится ли в пизду под напором реальных пользователей, которые как саранча, блядь, налетят.
Короче, это не про то, работает ли кнопка. Это про то, как она работает, когда на неё нажимают одновременно овердохуища народа. Основные виды, чтобы мозги не ебать:
| Вид тестирования | Суть вопроса, если по-простому |
|---|---|
| Нагрузочное (Load Testing) | А выдержит ли она, сука, обычный рабочий день, когда все пришли с обеда и начали тупить в интерфейс? |
| Стрессовое (Stress Testing) | А что будет, если на неё, блядь, свалится слава как на того самого кота и нагрузка вырастет в десять раз? Где она треснет первой? |
| Тестирование на выносливость (Soak Testing) | А не сольёт ли она всю оперативку и не сдохнет ли тихо, ебать, через 12 часов вялотекущей работы? |
| Спайковое (Spike Testing) | А если, хуй с горы, раз — и тысяча запросов в секунду? Не обоснётся ли? |
| Тестирование масштабируемости | А поможет ли, если мы добавим ещё один сервер, или это как мёртвому припарки? |
А что мы вообще меряем, бля? Ну, смотри:
- Время отклика — сколько ждать, пока страница откроется. Если больше трёх секунд, пользователь уже мысленно посылает тебя нахуй.
- Пропускная способность — сколько запросов в секунду она может проглотить, не подавившись.
- Потребление ресурсов — ЦП, память, диск. Чтобы сервер не пыхтел, как паровоз, и не светился красным.
- Ошибки — сколько раз она, блядь, упала и выдала «504 Gateway Timeout» вместо результата.
Вот, смотри, как это в JMeter'е примерно выглядит, код не трогаю, он святой:
Thread Group:
Number of Threads (users): 100 // Сто виртуальных юзеров, блядь, как на митинге.
Ramp-Up Period: 30 seconds // Подключаем их не всех сразу, а постепенно, за полминуты.
Loop Count: Forever // И пусть долбят систему, пока мы не скажем "стоп".
HTTP Request:
Server Name: api.example.com
Path: /v1/orders
Method: GET // Просто дергают АПИшку, получают заказы.А цель всей этой движухи, ёпта, какая? Найти узкие места — эти ебучие баттлнеки! Где тормозит: в медленной как говно БД, в кривом кэше или в том внешнем сервисе, который отвечает через жопу. Чтобы потом прийти к архитекторам и сказать: «Мужики, тут пиздец, а не масштабирование, надо чинить, иначе в продакшене будет волнение, ебать». Вот и вся философия.