Потоки, процессы и asyncio

Три инструмента и их цена

Асинхронность: один поток, задания уступают друг другу на ожидании. Дёшево по памяти, тысячи одновременных операций, но требует, чтобы ВЕСЬ код по пути был неблокирующим - одна синхронная строка ложит цикл.

Потоки: настоящие потоки операционной системы, переключается сама система. Работают с обычным синхронным кодом, ускоряют ожидание, но не ускоряют счёт из-за глобальной блокировки. Стоят памяти на стек каждого и требуют думать о гонках.

// Процессы: у каждого свой интерпретатор, своя память, свой замок - настоящая параллельность счёта. Плата: запуск в одиннадцать раз дороже потока (5,5 против 0,5 миллисекунды по моему замеру), память не общая, обмен данными идёт через передачу, а всё передаваемое должно поддаваться упаковке. Мой замер ускорения - 1,6 раза на двух ядрах, а не 2,0: часть времени уходит как раз на запуск и обмен.

асинхронность

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

поток

дёшев в запуске, ускоряет ожидание, но не счёт

процесс

своя память и свой интерпретатор; настоящая параллельность счёта

Как выбирать

Веб-сервис, который ходит в базу и в чужие сервисы, - это ожидание. Тут выигрывает асинхронность, а потоки идут вторым вариантом там, где библиотеки синхронные и переписывать их некогда.

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

// Про число рабочих процессов веб-сервиса. Для счётной нагрузки отправная точка - по числу ядер. Для ожидающей асинхронной - тоже по числу ядер, а масштаб даёт сама асинхронность внутри каждого. Формулы вида «два умножить на ядра плюс один» пришли из синхронных серверов и к асинхронным отношения не имеют. И в контейнере число ядер надо смотреть по ЛИМИТУ, а не по машине: приложение видит все ядра хоста и легко поднимет вдесятеро больше процессов, чем ему выделено.

число рабочих процессов

отправная точка - число доступных ядер, а не универсальная формула

лимит против машины

в контейнере считать надо по выделенным ядрам, а не по хостовым

Что общего и чем это опасно

У потоков общая память. Это удобно (не надо ничего передавать) и опасно (нужны замки, легко получить гонку). У процессов памяти нет общей вовсе - данные передаются копированием, и это отдельная статья расходов: передать большой массив между процессами может стоить дороже, чем посчитать его.

Отсюда типовая ошибка: разложить обработку миллиона мелких элементов по процессам и получить замедление, потому что упаковка и передача съели весь выигрыш. Лечится укрупнением порций: передавать не по элементу, а пачками.

// И отдельная вещь про запуск процессов: способ запуска влияет на поведение. При копировании родителя дочерний процесс наследует всё, включая открытые соединения к базе, и это ломается неожиданно. Поэтому соединения открывают ПОСЛЕ запуска дочерних процессов, а не до.

передача данных

между процессами данные копируются; на мелких порциях съедает выигрыш

наследование соединений

дочерний процесс получает открытые соединения родителя; их открывают после запуска

Как отвечать: «Потоки, процессы или async - как выбрать?»

По тому, чего в задаче больше: ожидания или счёта. Я мерил это на одной машине с двумя ядрами. Счётная задача в один поток - четыреста миллисекунд, вдвое больше работы в двух потоках - восемьсот сорок, ускорения нет из-за глобальной блокировки. Та же работа в двух процессах - пятьсот, ускорение в полтора раза. А ожидание в потоках ускоряется почти линейно. Поэтому: ждём - асинхронность или потоки; считаем - процессы. Асинхронность дешевле всех по памяти и тянет тысячи одновременных операций, но требует, чтобы весь код по пути был неблокирующим. Процессы дают настоящую параллельность, но запуск дороже потока раз в одиннадцать, а данные между ними копируются - на мелких порциях передача съедает весь выигрыш. Смешанный случай решаю разделением: ожидание в асинхронном коде, тяжёлый счёт в отдельный пул процессов.

Ответ выбирает по природе задачи, подкрепляет тремя замерами и называет цену каждого варианта. Замечание про копирование данных - то, обо что спотыкаются при первом переходе на процессы.

На чём валятся

• −Берут потоки для счёта и не получают ускорения.
• −Раскладывают по процессам мелкие порции: передача данных съедает выигрыш.
• −Оставляют в асинхронном коде синхронный вызов и теряют всю выгоду.
• −Считают число рабочих процессов по ядрам хоста, а не по лимиту контейнера.
• −Открывают соединения к базе до запуска дочерних процессов.