Я вряд ли верю, что число ожидающих выполнения задач или их краткое изложение многое скажут вам. Допустим, у вас есть 10000 задач, 8000 из них ожидают выполнения: это много, не так ли? Кто знает.
Дело в том, что каждая задача asyncio (или любой другой объект Python) может потреблять различное количество разных машинных ресурсов.
Вместо того, чтобы пытаться отслеживать asyncio конкретные объекты, я думаю, что лучше отслеживать общие показатели:
- загрузка процессора
- Использование ОЗУ
- Сетевой ввод / вывод (если вы имеете дело с ним)
- Ввод / вывод жесткого диска (на случай, если вы имеете дело с ним)
Что касается asyncio, вам, вероятно, следует всегда использовать asyncio.Semaphore , чтобы ограничить максимальное количество выполняемых в данный момент заданий и реализовать удобный способ изменения значения семафора (ов) (например, через config файл).
Это позволит изменять рабочую нагрузку на конкретную машину в зависимости от ее доступных и фактически используемых ресурсов.
Upd:
Мой вопрос, будет ли asyncio по-прежнему принимать новые подключения во время этого
блок
Если ваш цикл событий заблокирован каким-либо вычислением ЦП, asyncio начнет обрабатывать новые соединения позже - когда цикл событий снова станет свободным (если они не отключены по времени в этот момент).
Вы всегда должны избегать ситуации замораживания цикла событий. Заморозка где-то цикла событий означает, что все задачи в коде также замораживаются! Любой тип заморозки циклов разрушает саму идею использования асинхронного подхода независимо от количества задач. Любой код, в котором зациклен цикл обработки событий, будет иметь проблемы с производительностью.
Как вы заметили, вы можете использовать ProcessPoolExecutor с run_in_executor , чтобы ожидать загрузки ресурсов, связанных с процессором, но вы также можете использовать ThreadPoolExecutor, чтобы избежать зависания.