Зачем измерять производительность 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 и мониторьте их выполнение.