PHP Developer

Чурбанов Валерий · Senior PHP Developer · Резюме

Тема

API Performance ​

Раздел посвящён практикам управления нагрузкой и поведением API: throttle и debounce на клиенте, rate limiting на сервере, retry с backoff, идемпотентности, условному кэшированию и базовому нагрузочному тестированию.

Throttle — «не чаще одного раза за интервал» ​

Позволяет выполнять функцию не чаще одного раза за заданный промежуток времени, даже если событие происходит очень часто.

Используется для:

  • scroll;
  • resize;
  • drag&drop;
  • частых кликов.

Пример:

text
scroll происходит 100 раз в секунду
→ запрос отправляется только 1 раз в 200 мс

Debounce — «выполнить после паузы» ​

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

Используется для:

  • поиска при вводе;
  • autocomplete;
  • валидации формы.

Пример:

text
пользователь печатает текст
→ запрос не отправляется
→ пользователь остановился на 500 мс
→ отправляется один запрос

Rate Limit на сервере ​

Настраивал серверное ограничение количества запросов (per IP / per user / per token) на уровне веб-сервера (Nginx) и приложения (Laravel). Использовался для защиты API от злоупотреблений, ботов и всплесков нагрузки.

На практике работал с разными лимитами для разных групп endpoint-ов:

  • базовые API-запросы;
  • login / refresh / logout;
  • регистрация и восстановление доступа;
  • тяжёлые операции вроде export и download.

Идемпотентность небезопасных методов (POST) ​

Реализовывал идемпотентность небезопасных запросов (POST, PUT, PATCH, DELETE) с использованием idempotency-key, что позволяло безопасно повторять запросы при сетевых сбоях и retry-механизмах без дублирования операций.

На сервере это выглядит так:

  • cache key строится из ключа, метода, маршрута и identity;
  • успешный ответ может быть возвращён повторно как replay;
  • используются distributed lock и in-progress защита от гонок;
  • при конфликте сигнатуры возвращается 409, а при занятом запросе — Retry-After.

Заголовки в ответах API ​

  • X-RateLimit-Limit;
  • X-RateLimit-Remaining.

При превышении лимита ​

HTTP/1.1 429 Too Many Requests

Заголовок Retry-After

Retry + Backoff ​

Реализовывал повторные попытки запросов при временных ошибках с экспоненциальной задержкой. Подход повышал устойчивость клиент-серверного взаимодействия и снижал нагрузку на API при массовых отказах.

Использовал retry избирательно:

  • только для временных сетевых/инфраструктурных ошибок;
  • с ограниченным числом повторов;
  • с уважением к Retry-After, если сервер его возвращает;
  • в связке с Idempotency-Key, если операция небезопасная.

Conditional Requests и HTTP cache ​

Применял механизм условных запросов с использованием ETag, Cache-Control и 304 Not Modified для GET-endpoint-ов, чтобы снижать количество повторных полных ответов и сетевую нагрузку.

Такой подход особенно полезен для:

  • списков и каталогов;
  • пользовательских коллекций;
  • изображений и других часто запрашиваемых ресурсов.

Кэширование ​

Применял различные техники кэширования (HTTP-кэширование, server-side cache, client-side cache) для снижения latency и количества повторных запросов.

Нагрузочное тестирование ​

Проводил базовое нагрузочное тестирование API/web-сценариев для оценки throughput, latency и хвостовых задержек.

Использовал:

  • k6 и scripted traffic scenarios;
  • контроль p95/p99, error rate и dropped iterations;
  • проверку устойчивости на пограничных значениях нагрузки;
  • сравнение публичных и авторизованных сценариев.

См. также ​

Сайт обновлен и проверен: