Производительность API - это не только про "быстро или медленно". Для QA это тема про устойчивость сервиса под реальной нагрузкой, предсказуемость ответа и влияние backend на пользовательский опыт. Один и тот же endpoint может технически работать, но при этом давать плохой UX: экран долго крутится, происходят таймауты, включаются лишние retry, дублируются операции и начинают сыпаться зависимые сервисы.
Поэтому даже если QA не занимается полноценным performance testing каждый день, он всё равно должен понимать базовые признаки проблем. Это помогает раньше замечать риск и не оставлять performance только на "потом разберёмся".
Что вообще считать проблемой производительности
Частая ошибка - думать, что performance-проблема есть только тогда, когда система совсем перестала отвечать. На практике всё начинается раньше.
- →оно отвечает заметно медленнее ожидаемого для этого сценария
- →время ответа сильно плавает от запроса к запросу
- →при росте нагрузки резко растёт latency или количество ошибок
- →тяжёлые запросы начинают ломать соседние сценарии
- →сервис формально отвечает, но пользователю приходится ждать слишком долго
Для QA это важно, потому что функционально endpoint может быть "зелёным", а по факту уже находиться в зоне риска.
Какие метрики QA должен понимать
На старте не нужно превращаться в performance engineer, но несколько понятий нужно знать уверенно.
- →Latency - сколько времени занимает ответ. Это то, что чаще всего первым замечает пользователь.
- →Throughput - сколько запросов система реально переваривает за единицу времени.
- →Error rate - как меняется количество ошибок под нагрузкой.
- →Saturation - насколько система упирается в свои лимиты: CPU, память, соединения, пул потоков, база, очередь.
Особенно важно понимать одну вещь: среднее значение почти всегда обманывает. Если endpoint в среднем отвечает за 300 мс, это ещё не означает, что всё хорошо. Может оказаться, что половина запросов очень быстрые, а часть пользователей ждёт по 5-8 секунд. Поэтому для API гораздо полезнее смотреть не только на average, но и на percentiles, например p95 и p99.
Для QA практический смысл такой: performance-проблема часто живёт не в "обычном среднем запросе", а в хвосте распределения, где система начинает вести себя нестабильно.
Что чаще всего замедляет API
Причин обычно несколько, и они не всегда лежат в одном месте.
- →тяжёлые запросы к базе
- →отсутствие нужных индексов
- →плохая pagination или сортировка на большом объёме данных
- →N+1 запросы
- →слишком большой payload
- →синхронные вызовы медленных зависимостей
- →дорогая сериализация и десериализация
- →лишняя бизнес-логика в одном endpoint
- →блокировки и конкуренция за один и тот же ресурс
- →агрессивные retry, которые сами усиливают перегрузку
Для QA это полезно не ради оптимизации кода, а ради правильных гипотез. Если медленно работает список с фильтрами, подозрение часто падает на базу, индексы, сортировку и объём данных. Если проседает оформление заказа, проблема может быть не только в orders service, а в синхронном вызове оплаты, склада или antifraud.
Что реально может делать QA без отдельной perf-лаборатории
Даже без JMeter, k6 и выделенной среды QA может замечать очень много.
- →сравнивать время ответа между похожими сценариями
- →смотреть, как меняется ответ на маленьком и большом объёме данных
- →проверять один и тот же endpoint с разными фильтрами, сортировками и page size
- →замечать, где система нестабильна даже на обычном функциональном прогоне
- →обращать внимание на таймауты, 429, 502, 503, 504
- →фиксировать, если после замедления начинаются повторы операций, дубли и рассинхронизация
- →поднимать perf-risk ещё до полноформатного load test, если по дизайну endpoint выглядит тяжёлым
Это важный момент: QA не обязан сразу строить большой нагрузочный стенд, чтобы увидеть сигнал риска. Часто уже обычное функциональное тестирование показывает, что сценарий ведёт себя подозрительно.
На что смотреть в обычной работе
Есть несколько практических признаков, которые стоит воспринимать как warning signal.
- →одинаковые запросы дают сильно разное время ответа
- →на тестовых данных всё нормально, а на больших объёмах список разваливается
- →фильтры и сортировка резко ухудшают response time
- →создание объекта быстрое, а чтение списка этого же объекта очень медленное
- →при нескольких одновременных действиях интерфейс начинает врать о статусе
- →после замедления включаются retry и появляются дубли
- →сервис отвечает 200, но настолько медленно, что пользователь уже перезагружает страницу или нажимает кнопку повторно
Для QA это особенно важно в критичных бизнес-потоках: логин, поиск, оплата, оформление заказа, обновление статусов, работа со списками и аналитикой.
Почему производительность и надёжность связаны
Новички часто думают, что performance - это отдельная тема, не связанная с качеством логики. На практике всё наоборот. Медленный API часто запускает цепочку побочных эффектов:
- →пользователь повторно нажимает кнопку
- →frontend делает повторный запрос
- →gateway или client library срабатывает по timeout/retry
- →downstream сервисы получают лишнюю нагрузку
- →очередь начинает расти
- →часть операций успевает завершиться, а часть нет
- →появляются дубли и странные статусы
То есть performance-проблема быстро перестаёт быть только про скорость. Она превращается в проблему корректности и устойчивости системы.
Практический пример
Представь endpoint списка заказов: GET /orders?status=paid&sort=created_at_desc&limit=50
На маленьком наборе данных он отвечает за 150 мс. На реальном объёме данных ответ начинает занимать 4-6 секунд, а иногда и больше.
Что важно QA:
- →замедление связано именно с сортировкой и фильтрацией или вообще со списком целиком
- →проблема появляется на определённом размере данных или сразу
- →после замедления фронт начинает делать повторные запросы или показывать ложные ошибки
- →не ломается ли pagination
- →не расходятся ли count и реальные данные
- →не тянет ли endpoint слишком большой payload
- →не приводит ли этот медленный запрос к деградации других API
Внешне это может выглядеть как "список тормозит". Но с точки зрения качества продукта это уже риск таймаутов, дублей, плохого UX и будущих инцидентов на проде.
Что должен вынести QA из этой темы
- →Производительность API - это не только скорость, но и предсказуемость поведения под нагрузкой.
- →Среднее время ответа почти никогда не даёт полной картины, поэтому важно понимать смысл p95 и p99.
- →Медленный endpoint часто ломает не только UX, но и корректность сценария через retry, таймауты и дубли.
- →QA может замечать perf-risk даже без полноценной нагрузочной лаборатории.
- →Один из самых полезных навыков здесь - увидеть, какой именно сценарий или параметр делает API дорогим и нестабильным.
Что ещё почитать
- →Внутри базы: Pagination, Filtering, Sorting
- →Внутри базы: Database testing
- →Внешний материал: Grafana k6: API load testing
- →Внешний материал: MDN: Latency
- →Внешний материал: AWS: Throughput vs Latency