Что такое latency и throughput

Latency (задержка) — это время, которое проходит между отправкой запроса и получением соответствующего ответа или завершением операции. Её измеряют в единицах времени: миллисекунды (ms), секунды (s). Latency складывается из нескольких частей: сетевой RTT, время в очереди (queueing), время обработки на сервере (service time), время чтения/записи данных и т.д. Важно различать время обработки (service time) и end-to-end latency (включая очереди и задержки у зависимостей).

Ключевые понятия по latency:

• p50 (медиана) — половина запросов быстрее этого значения.

• p95 / p99 / p999 (перцентили) — 95%, 99% и 99.9% запросов быстрее этих значений; tail latency (хвост) часто критичнее среднего.

• Среднее (mean) — чувствительно к выбросам; часто вводит в заблуждение.

• Histogram / HDR-histogram — дают распределение задержек, позволяют корректно считать перцентили.

Почему хвостовая задержка важна: небольшая доля медленных запросов (p99) может создать заметные проблемы UX и сломать SLA, даже при хороших значениях p50.

Throughput (пропускная способность) — это количество операций/запросов, которые система обрабатывает за единицу времени. Единицы: запросы в секунду (req/s), транзакции в секунду (TPS), байты в секунду (B/s). Throughput показывает нагрузку и ёмкость системы.

Важные аспекты:

• Пиковая vs устойчивая пропускная способность.

• Throughput ограничивается узким местом (база данных, сеть, диск, CPU).

• Увеличение нагрузки не всегда линейно повышает throughput — при насыщении ресурсами throughput может упасть или начать расти медленнее.

Взаимосвязь: Little’s Law (простая модель)

Little’s Law: L=λ×WL = \lambda \times W, где
LL — среднее число одновременно находящихся запросов (concurrency),
λ\lambda — throughput (req/s),
WW — средняя задержка (s).

Отсюда λ=L/W\lambda = L / W.

Пример расчёта (пошагово):

• Пусть одновременно обрабатывается L=100L=100 запросов.

• Средняя задержка W=200W = 200 ms.

• 200 ms = 200÷1000=0,2200 \div 1000 = 0{,}2 s. (деление: 200/1000 = 0.2)

• Тогда throughput λ=100÷0,2=500\lambda = 100 \div 0{,}2 = 500 req/s. (деление: 100/0.2 = 500)

Эта формула объясняет, почему при росте latency без увеличения параллелизма throughput падает, и наоборот — увеличение concurrency при той же задержке повышает throughput.

Точки конфликта и компромиссы

• Бэтчинг и агрегация увеличивают throughput (больше работы за один вызов), но повышают latency для отдельных запросов.

• Параллелизм повышает throughput, но может привести к контеншену ресурсов и росту latency (queueing).

• Ретраи (повторные попытки) могут искусственно увеличить нагрузку и ухудшить и latency, и throughput.

• Backpressure и rate-limiting помогают сохранить устойчивость, жертвуя частью throughput ради стабильного latency.

Что измерять и как улучшать

Метрики: p50/p95/p99 latency по эндпоинтам, successful req/s (throughput), CPU/memory/IO, queue depth, connection pool usage, error rate. Инструменты: APM, Prometheus (histograms), HDR Histogram, Jaeger/Zipkin (tracing), нагрузочное тестирование (k6, JMeter).

Способы улучшения: кэширование, сокращение критического пути, асинхронная обработка, пул соединений, горизонтальное масштабирование, оптимизация запросов к БД, CDN, контроль ретраев, внедрение backpressure и адаптивного rate-limiting.