Выбор между потоками, процессами и asyncio для нагрузки Python

Цель

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

Предварительные условия

Профиль или измерение, показывающее, на что уходит время в горячем пути: ожидание ввода-вывода (сокеты, диски, подпроцессы), выполнение байткода Python (разбор, вычисления на чистом Python) или выполнение нативного кода, освобождающего GIL (сжатие, хеширование, многие операции с массивами). См. «Профилируйте перед оптимизацией».

Шаги

1. Подсчитайте одновременные ожидания. Тысячи соединений или изначально асинхронные библиотеки указывают на asyncio. Несколько десятков блокирующих вызовов через синхронные библиотеки — на ThreadPoolExecutor; документация указывает число рабочих потоков по умолчанию min(32, cpu_count + 4) (на основе os.process_cpu_count() начиная с 3.13), выбранное так, чтобы сохранить хотя бы пять потоков для задач, ограниченных вводом-выводом.
2. Если узкое место — байткод Python, потоки не помогут в стандартной сборке: глоссарий определяет GIL как механизм, позволяющий только одному потоку одновременно выполнять байткод Python. Используйте ProcessPoolExecutor (или multiprocessing) либо сборку со свободной многопоточностью, если её поддерживают все зависимости.
3. Если узкое место — нативный код, освобождающий GIL, потоки дают параллелизм без затрат процессов на сериализацию; подтвердите это запуском с двумя рабочими потоками против одного на реальных данных.
4. Для процессов явно задайте способ запуска через get_context(). Документация указывает, что в POSIX значение по умолчанию изменилось с fork на forkserver в Python 3.14, а в macOS с 3.8 по умолчанию используется spawn; аргументы и результаты должны допускать сериализацию pickle, поэтому передавайте идентификаторы вместо крупных объектов и открывайте соединения в initializer рабочего процесса.
5. Ограничивайте всё: max_workers, asyncio.Semaphore или размер очереди; неограниченное разветвление переносит отказ на нижестоящий сервис.
6. Сочетайте модели осознанно: asyncio.to_thread для блокирующего вызова внутри цикла, loop.run_in_executor с пулом процессов для вычислительной работы в асинхронном сервере.
7. Пропишите завершение работы: executor.shutdown(cancel_futures=True), отмену задач и тайм-аут для каждого future.result().

Ожидаемый результат

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

Ограничения и основание проверки

Правила следуют приведённой документации, а не измерениям. Смешанным нагрузкам могут потребоваться два пула. Сборки со свободной многопоточностью меняют шаг 2; см. статью о GIL и открытый вопрос о том, когда такие сборки окупаются.