Метрики производительности API

Зачем измерять производительность API

API документацию — основа современных веб-приложений. Медленный API означает медленный сайт, плохой пользовательский опыт и потерю клиентов. По данным Amazon, каждые 100 мс задержки снижают продажи на 1%. Для API, обслуживающих фронтенд, это критично.

Без метрик вы не знаете, насколько быстро работает API, где узкие места и когда начинается деградация.

Ключевые метрики

Latency (задержка)

Время от отправки запроса до получения ответа. Главная метрика пользовательского опыта.

Как измерять:

• Среднее значение (average) — обманчиво. Может скрывать проблемы: если 99 запросов по 100 мс и 1 по 10 секунд, среднее — 199 мс
• Медиана (P50) — 50% запросов быстрее этого значения. Характеризует типичный опыт
• P95/P99 — 95%/99% запросов быстрее. Показывает «хвост» распределения — опыт худших запросов
• P99.9 — для high-traffic API, критично для SLA

Целевые значения:

• P50: менее 100 мс для внутренних API, менее 200 мс для публичных
• P95: менее 500 мс
• P99: менее 1 секунды

Throughput (пропускная способность)

Количество запросов, обрабатываемых в единицу времени (RPS — Requests Per Second). Показывает ёмкость системы.

Мониторьте throughput в связке с latency. Увеличение RPS часто вызывает рост latency — важно знать точку, где начинается деградация.

Error Rate (частота ошибок)

Процент запросов, завершившихся ошибкой (HTTP 4xx, 5xx). Цель — менее 0.1% для 5xx ошибок.

Различайте:

• 4xx — ошибки клиента (валидация, авторизация). Не всегда проблема сервера
• 5xx — ошибки сервера. Всегда требуют внимания
• Timeout — запрос не получил ответа. Часто самая вредная ошибка

Availability (доступность)

Процент времени, когда API отвечает корректно. SLA обычно определяет целевой uptime:

• 99.9% — не более 8.7 часов простоя в год
• 99.99% — не более 52.5 минут в год

Saturation (насыщение)

Насколько загружены ресурсы: CPU, память, соединения с БД, дисковый I/O. Когда saturation приближается к 100%, latency резко растёт.

Методология RED

RED (Rate, Errors, Duration) — простая методология для мониторинг сайтов микросервисов:

• Rate — количество запросов в секунду
• Errors — количество неудачных запросов в секунду
• Duration — распределение времени ответа (гистограмма)

Эти три метрики покрывают 80% потребностей в мониторинге API.

Оптимизация производительности API

Запросы к базе данных

• Используйте индексы для частых запросов
• Избегайте N+1 проблемы (1 запрос для списка + N запросов для деталей)
• Кэшируйте результаты часто повторяющихся запросов в Redis
• Используйте пагинацию вместо загрузки всех записей

Кэширование

• Redis/Memcached для горячих данных
• HTTP кэширование (Cache-Control, ETag) для публичных эндпоинтов
• Мемоизация вычислений внутри запроса

Компрессия

Включите gzip/brotli для JSON-ответов. Для большого JSON-ответа сжатие может уменьшить размер на 80-90%.

Пагинация и фильтрация

Не возвращайте 10,000 записей одним ответом. Используйте cursor-based или offset-based пагинацию. Позвольте клиентам фильтровать данные на стороне сервера.

Мониторинг и инструменты

Используйте HTTP-чекер Enterno.io для проверки времени отклика и заголовков ваших API-эндпоинтов. Настройте мониторинг uptime для ключевых эндпоинтов, чтобы получать уведомления при деградации.

Итоги

Мониторьте latency (percentiles, не averages), throughput, error rate и saturation. Используйте методологию RED для микросервисов. Оптимизируйте запросы к БД, кэшируйте горячие данные, сжимайте ответы. Устанавливайте SLA и мониторьте их выполнение.