Как измеряется latency
Latency описывают через распределение, а не одно число. Стандартный набор метрик:
| Метрика | Что означает |
|---|---|
| p50 (медиана) | Половина запросов выполняется быстрее этого значения |
| p95 | 95% запросов выполняется быстрее; 5% — медленнее |
| p99 | 99% запросов выполняется быстрее; 1% — медленнее («хвост») |
| p999 | Применяется для систем с очень строгими требованиями |
Распределение latency (мс):
p50 = 12 мс ← типичный быстрый запрос
p95 = 38 мс ← 5% чуть медленнее
p99 = 87 мс ← «хвосты» — кэш-мисс, GC-паузы
p999 = 420 мс ← редкие выбросы
SLA платформы персонализации обычно задаётся через p99 — это «гарантированное» поведение системы, исключая редчайшие аномалии.
Источники задержки в API персонализации
Итоговая latency складывается из нескольких компонент:
- Сетевая задержка (RTT) — время в пути до дата-центра и обратно. Снижается через CDN и размещение поближе к пользователям.
- Очередь на сервере — при пиковой нагрузке запросы ждут освобождения воркера.
- Вычисление рекомендаций — поиск ближайших соседей по векторной базе или применение модели ранжирования.
- Доступ к данным — чтение профиля пользователя, истории, контекста сессии из хранилища.
- Сериализация ответа — формирование JSON и его сжатие.
Совет: кэшируйте предвычисленные рекомендации для популярных сценариев (топ товаров, часто просматриваемые категории). Персонализированные рекомендации пересчитывайте асинхронно, а не в критическом пути загрузки страницы — это снижает p99 на порядок.
Latency и Core Web Vitals
В контексте загрузки страницы latency API персонализации прямо влияет на LCP (Largest Contentful Paint), если рекомендательный виджет попадает в критический рендеринг. Рекомендательные блоки в подвале страницы или под fold не влияют на LCP, что делает lazy loading виджетов стандартной практикой для оптимизации Core Web Vitals при работе с платформами персонализации.