Choisir entre threads, processus et asyncio pour une charge de travail Python

Objectif

Choisir le modèle de concurrence adapté au goulot d'étranglement de la charge de travail avant que la conception ne se fige autour du mauvais choix.

Prérequis

Un profilage ou une mesure indiquant où passe le temps sur le chemin critique : attente d'E/S (sockets, disques, sous-processus), exécution de bytecode Python (analyse syntaxique, calcul numérique en Python pur), ou exécution de code natif qui libère le GIL (compression, hachage, nombreuses opérations sur tableaux). Voir « Profiler avant d'optimiser ».

Étapes

1. Compter les attentes concurrentes. Des milliers de connexions, ou des bibliothèques nativement asynchrones, orientent vers asyncio. Quelques dizaines d'appels bloquants passant par des bibliothèques synchrones orientent vers un ThreadPoolExecutor ; la documentation indique que son nombre de travailleurs par défaut est min(32, cpu_count + 4) (fondé sur os.process_cpu_count() depuis la 3.13), choisi pour préserver au moins cinq travailleurs pour les tâches liées aux E/S.
2. Si le goulot d'étranglement est le bytecode Python, les threads n'aident pas sur la build par défaut : le glossaire définit le GIL comme le mécanisme qui ne permet qu'à un seul thread d'exécuter du bytecode Python à la fois. Utiliser ProcessPoolExecutor (ou multiprocessing), ou une build sans GIL (free-threaded) si toutes les dépendances la prennent en charge.
3. Si le goulot d'étranglement est du code natif qui libère le GIL, les threads offrent du parallélisme sans le coût de sérialisation des processus ; confirmer par une exécution à deux travailleurs contre un seul sur des données réelles.
4. Pour les processus, fixer explicitement la méthode de démarrage avec get_context(). La documentation indique que, sur POSIX, la valeur par défaut est passée de fork à forkserver en Python 3.14, et que macOS utilise spawn par défaut depuis la 3.8 ; les arguments et résultats doivent être sérialisables (picklable), donc passer des identifiants plutôt que de gros objets et ouvrir les connexions dans l'initializer du travailleur.
5. Tout borner : max_workers, un asyncio.Semaphore, ou une taille de file d'attente ; un déploiement non borné déplace la panne vers le service en aval.
6. Combiner les modèles délibérément : asyncio.to_thread pour un appel bloquant à l'intérieur d'une boucle, loop.run_in_executor avec un pool de processus pour du calcul intensif à l'intérieur d'un serveur asynchrone.
7. Écrire le chemin d'arrêt : executor.shutdown(cancel_futures=True), l'annulation des tâches, et un délai d'expiration sur chaque future.result().

Résultat attendu

Une courte note de décision nommant le goulot d'étranglement, le modèle, la borne et la méthode de démarrage, plus un petit banc d'essai montrant que le modèle choisi bat la référence monothread sur la charge réelle.

Limites et base de vérification

Les règles suivent la documentation citée, pas des mesures. Les charges mixtes peuvent nécessiter deux pools. Les builds sans GIL modifient l'étape 2 ; voir l'article sur le GIL et la question ouverte sur le moment où de telles builds sont rentables.