LATENCY VS THROUGHPUT

Когда пользователи говорят что приложение «тормозит», причина может быть в двух плоскостях:

* проблема latency (каждый запрос обрабатывается медленно)
* проблема throughput (система забита и не тянет нагрузку)

Иногда это вообще смесь обоих.

Latency — время, которое сервер тратит на выполнение одного запроса от начала до ответа.

Throughput — сколько запросов сервер способен обработать за единицу времени.

Представим, что ты инженер в сервисе доставки пиццы.

Сценарий 1:
Пользователь нажимает «Отправить заказ» и ответ долго крутится — значит высокий latency. Для пользователя это воспринимается как «всё лагает».
Низкий latency = быстрый отклик для каждого конкретного запроса.

Сценарий 2:
Ответы идут примерно по 100 мс — вроде норм. Но если система способна держать только 10 запросов в секунду, а одновременно приходит тысяча, всё разваливается. Это низкий throughput.
Высокий throughput = возможность обслуживать много пользователей одновременно.

Обе метрики критичны, особенно когда система растёт по нагрузке.

* Ответы быстрые, но при всплеске трафика сыпятся таймауты — проблема в throughput.
* Каждый запрос тормозит даже при маленьком трафике — проблема в latency.

» Как чинят проблемы с latency (ускоряем отдельные запросы)

Причины: медленные SQL-запросы, тяжёлые внешние API, прожорливая логика, геолокация сервера и так далее.
Обычно помогают индексы в БД, кэширование, оптимизация кода, CDN, профилирование узких мест.

» Как фиксят проблемы с throughput (увеличиваем пропускную способность)

Обычно упирается в ресурсы. Масштабирование: больше серверов, балансировка нагрузки, кэширование, горизонтальное расширение и т. п.

P.S. Для пользовательских API чаще гонятся за низким latency, а для фоновых задач типа batch-процессинга чаще важнее throughput, чем скорость каждого отдельного задания.

Всё упирается в то, под что именно ты оптимизируешься.

👉 Java Portal