Elegir entre hilos, procesos y asyncio para una carga de trabajo en Python

Objetivo

Elegir el modelo de concurrencia que coincide con el cuello de botella de la carga de trabajo antes de que el diseño se consolide en torno a uno equivocado.

Requisitos previos

Un perfilado o una medición que indique adónde va el tiempo en la ruta crítica: espera de E/S (sockets, discos, subprocesos), ejecución de bytecode de Python (análisis sintáctico, cálculo numérico en Python puro), o ejecución de código nativo que libera el GIL (compresión, hashing, numerosas operaciones con arrays). Véase «Perfilar antes de optimizar».

Pasos

1. Contar las esperas concurrentes. Miles de conexiones, o bibliotecas nativamente asíncronas, apuntan a asyncio. Unas pocas decenas de llamadas bloqueantes a través de bibliotecas síncronas apuntan a un ThreadPoolExecutor; la documentación indica que su número de workers por defecto es min(32, cpu_count + 4) (basado en os.process_cpu_count() desde la versión 3.13), elegido para conservar al menos cinco workers para tareas limitadas por E/S.
2. Si el cuello de botella es el bytecode de Python, los hilos no ayudan en la compilación por defecto: el glosario define el GIL como el mecanismo que permite que solo un hilo ejecute bytecode de Python a la vez. Usar ProcessPoolExecutor (o multiprocessing), o una compilación sin GIL (free-threaded) si todas las dependencias la admiten.
3. Si el cuello de botella es código nativo que libera el GIL, los hilos ofrecen paralelismo sin el costo de serialización de los procesos; confirmarlo con una comparación entre dos workers y uno sobre datos reales.
4. Para los procesos, establecer explícitamente el método de arranque con get_context(). La documentación indica que en POSIX el valor por defecto cambió de fork a forkserver en Python 3.14 y que macOS usa spawn por defecto desde la 3.8; los argumentos y resultados deben ser serializables con pickle, por lo que conviene pasar identificadores en lugar de objetos grandes y abrir las conexiones dentro del initializer del worker.
5. Acotar todo: max_workers, un asyncio.Semaphore, o el tamaño de una cola; un fan-out sin límite traslada el fallo al servicio de destino.
6. Combinar modelos de forma deliberada: asyncio.to_thread para una llamada bloqueante dentro de un loop, loop.run_in_executor con un pool de procesos para trabajo de CPU dentro de un servidor asíncrono.
7. Escribir la ruta de apagado: executor.shutdown(cancel_futures=True), cancelación de tareas, y un tiempo límite en cada future.result().

Resultado esperado

Una breve nota de decisión que nombre el cuello de botella, el modelo, el límite y el método de arranque, junto con un pequeño benchmark que muestre que el modelo elegido supera a la línea base de un solo hilo en la carga de trabajo real.

Límites y base de verificación

Las reglas siguen la documentación citada, no mediciones. Las cargas de trabajo mixtas pueden necesitar dos pools. Las compilaciones sin GIL (free-threaded) cambian el paso 2; véase el artículo sobre el GIL y la pregunta abierta sobre cuándo compensan tales compilaciones.