Асинхронность и параллелизм в Python

sem = asyncio.Semaphore(10)   # лимит fan-out
async def fetch(u):
    async with sem:
        return await client.get(u)
await asyncio.gather(*map(fetch, urls))

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 8, остальные разбираются в тренажёре.

1. #async_concurrency1 / 5
   Когда для параллелизма берут multiprocessing, а когда threading?

   A)Брать процессы: они быстрее потоков благодаря обходу GIL на всех задачах

   B)Процессы — для CPU-bound (обходят GIL), потоки — для I/O-bound (ждут сеть/диск, GIL отпущен)

   C)Брать потоки: из-за GIL процессы в Python не дают выигрыша

   D)Выбор между ними определяется лишь объёмом данных в байтах, а не характером нагрузки

   показать ответ и разбор

   +B)Процессы — для CPU-bound (обходят GIL), потоки — для I/O-bound (ждут сеть/диск, GIL отпущен)

   // разбор: Из-за GIL потоки не ускоряют CPU-bound код (парсинг, вычисления) — тут нужны процессы, у каждого свой интерпретатор и ядро. Зато на I/O-bound (много сетевых/дисковых ожиданий) потоки эффективны: пока один ждёт, GIL отпущен и работает другой, а процессы были бы лишними накладными. Правило: считаем — процессы, ждём — потоки/async.

2. #async_concurrency2 / 5
   Для чего в пайплайне применяют async/await?

   A)Ускорять тяжёлые вычисления, распараллеливая их по всем ядрам процессора автоматически

   B)Исполнять код строго последовательно, исключая конкурентность между корутинами

   C)Кооперативная конкурентность для I/O-bound без множества потоков

   D)Заменять собой базы данных, храня состояние пайплайна прямо внутри цикла событий asyncio

   показать ответ и разбор

   +C)Кооперативная конкурентность для I/O-bound без множества потоков

   // разбор: async/await даёт кооперативную конкурентность: одна корутина на время ожидания I/O (запрос к API, БД) добровольно уступает управление, и event loop запускает другую готовую. Тысячи одновременных сетевых операций ведутся одним потоком без накладных расходов на тысячи потоков. Выигрыш только на I/O-bound; на CPU-bound async не помогает (один поток всё равно считает по очереди).

3. #async_concurrency3 / 5
   Зачем брать concurrent.futures.ThreadPoolExecutor для батча HTTP-запросов?

   A)Ускорять вычислительные CPU-bound задачи, обходя ограничение GIL интерпретатора

   B)Обеспечить строго последовательное выполнение запросов ровно в том порядке, в каком они были отправлены в пул

   C)Создавать отдельный поток ОС под каждый входящий запрос без ограничений

   D)Выполнять множество I/O-запросов конкурентно через пул потоков с простым map/submit-интерфейсом

   показать ответ и разбор

   +D)Выполнять множество I/O-запросов конкурентно через пул потоков с простым map/submit-интерфейсом

   // разбор: ThreadPoolExecutor держит фиксированный пул потоков и раздаёт им задачи (submit/map). Для I/O-bound батча (сотни HTTP-запросов) это резко ускоряет: пока потоки ждут ответов, GIL отпущен и они ждут параллельно, а размер пула ограничивает одновременную нагрузку на downstream. Проще ручного управления потоками и без переписывания на async.

4. #async_concurrency4 / 5
   Почему async/await не ускоряет тяжёлую CPU-bound трансформацию?

   A)Event loop однопоточный: пока корутина считает, она не уступает управление — конкуренции нет

   B)Ускоряет, потому что asyncio незаметно распределяет вычисления по нескольким ядрам процессора в фоне

   C)Не ускоряет, потому что async медленнее обычного синхронного кода

   D)Не ускоряет, если забыть поставить ключевое слово await перед вызовом трансформации

   показать ответ и разбор

   +A)Event loop однопоточный: пока корутина считает, она не уступает управление — конкуренции нет

   // разбор: async даёт конкурентность только когда корутины уступают управление на await (обычно на I/O). CPU-bound код не ждёт, он считает — и, не встречая await, монопольно держит единственный поток event loop, блокируя все прочие корутины. Параллелизма по ядрам у asyncio нет. Тяжёлые вычисления выносят в пул процессов (run_in_executor с ProcessPool), а не оборачивают в async.

5. #async_concurrency5 / 5
   Пул из 200 потоков шлёт запросы в сервис, и тот начинает падать. Что улучшить?

   A)Увеличить пул до 500 потоков — больше параллелизма даёт выше пропускную способность

   B)Ограничить конкурентность (семафор/меньший пул), чтобы не превышать пропускную способность downstream

   C)Убрать таймауты, чтобы запросы дожидались ответа перегруженного сервиса

   D)Ретраить упавшие запросы немедленно и без ограничений, пока сервис наконец не ответит успешно

   показать ответ и разбор

   +B)Ограничить конкурентность (семафор/меньший пул), чтобы не превышать пропускную способность downstream

   // разбор: Неограниченная конкурентность легко превышает то, что downstream держит, и валит его (а заодно себя ретраями). Вводят backpressure: семафор или пул фиксированного размера, ограничивающий число одновременных запросов до безопасного, плюс таймауты и ретраи с backoff. Цель — не «жать на газ», а держать нагрузку в пределах ёмкости приёмника.