Почему синхронный Python-фреймворк может не справляться с высокой нагрузкой при большом количестве внешних вызовов?

Суть проблемы: при большом количестве внешних вызовов время ответа становится суммой ожиданий, а синхронный воркер всё это время занят.

Определение

Синхронная обработка — модель, где выполнение запроса идёт последовательно, и I/O-вызовы блокируют текущий поток/воркер до завершения.

Типичный механизм деградации

Сначала один воркер “держит” запрос, пока ждёт сеть/БД. Затем при росте RPS:

1. Воркеры исчерпываются

   • каждый запрос занимает воркер на долгое время (ожидания внешних систем)

2. Очередь растёт

   • новые запросы ждут свободный воркер

3. Latency взлетает

   • даже быстрые запросы становятся медленными из-за очереди

4. Timeout cascade

   • клиент отваливается по таймауту, но воркер продолжает работу

   • появляются ретраи → нагрузка растёт ещё сильнее

Почему “просто добавить воркеров” не всегда решение

Перед перечислением зафиксируем: масштабирование воркеров полезно, но имеет предел.

1. Память

   • процессы/потоки требуют памяти (стек, объекты, буферы)

2. Context switching

   • слишком много потоков → расходы на переключение контекста

3. Сопутствующие лимиты

   • соединения к БД, file descriptors, лимиты внешних API

Мини-пример проблемы (последовательные ожидания)

def handler():
    r1 = http_call_1()  # блокирует
    r2 = http_call_2()  # блокирует
    return merge(r1, r2)

Даже если CPU почти не используется, воркер “занят” ожиданием.

Что помогает в таких сценариях

1. Асинхронные клиенты/драйверы и event loop

2. Параллелизация внешних вызовов (с лимитами)

3. Кеширование и батчинг

4. Очереди/фоновые задачи для долгих операций

Вывод

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