Laboratorio ejecutable · Bloque 1
EX-B1-08
Elegir async desde un perfil real
Antes de cambiar tres endpoints a `async def`, el equipo ha medido cuánto tiempo consume cada uno en CPU y cuánto espera a sistemas externos. Solo hay un worker de proceso durante la prueba.
Cómo abordarla
Observa el fundamento construyendo una API
Descarga el starter, predice un resultado, ejecuta, modifica la API y vuelve a observar. La explicación breve acompaña al código; no lo sustituye.
Abrir laboratorio de código
1. Descarga y arranca
- Starter ejecutable de concurrenciaTres endpoints defectuosos, dobles deterministas y prueba temporal concurrente.
- Perfil de endpointsMediciones por endpoint y plantilla breve de revisión.
2. Escribe y prueba
- Ejecuta el baseline secuencial y concurrente y conserva la cronología del fallo.
- Haz no bloqueante la espera del proveedor en `/shipping-quotes` y mantén la generación CPU fuera del event loop.
- Repara `/imports` separando la espera del webhook del parseo síncrono sin ocultar el coste de CPU.
- Añade una prueba que ejecute dos requests concurrentes, demuestre solapamiento del I/O y conserve respuestas correctas.
3. Demuestra el comportamiento
- Código de los tres endpoints y prueba concurrente verde.
- Cronología antes/después con duración total y orden de eventos.
- Nota breve que justifique cada frontera `def`/`async def` por la llamada concreta.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
Antes de editar, ¿qué dos peticiones deberían solaparse y cuál seguirá necesitando una frontera distinta aunque cambies la firma a async?
Información que necesitas
Profile window: 100 local requests, median per request, one process worker
GET /shipping-quotes
cpu_ms=7 upstream_wait_ms=418 file_wait_ms=0
POST /reports/monthly
cpu_ms=870 file_wait_ms=34 upstream_wait_ms=0
POST /imports
cpu_ms=312 upload_read_wait_ms=48 webhook_wait_ms=195
Constraints
- The shipping provider and webhook clients expose non-blocking APIs.
- PDF generation is a synchronous CPU-bound function.
- No extra process or background job system is active in this measurement.Comprueba estas tres cosas
- Identifica la fase dominante de cada endpoint.
- Recomienda `async`, mantener código síncrono o separar trabajo, citando la medición.
- Explica qué mejora esperas concurrentes y qué requeriría paralelismo u otro diseño.
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Compara magnitudes
- 418 frente a 7 describe un perfil muy distinto de 870 frente a 34.
Pista 2 · Async necesita I/O no bloqueante
- Una función `async def` que llama a una librería bloqueante sigue bloqueando el event loop.
Pista 3 · Separa CPU
- La concurrencia permite aprovechar esperas; acelerar cálculo activo exige paralelismo, optimización o sacar el trabajo de la request.
Profundización opcional
Reproducir el bloqueo, elegir `def` o `async def` por la llamada real y demostrar que las esperas externas se solapan sin ejecutar CPU prolongada en el event loop.
Contexto adicional
- Las medidas son medianas de 100 peticiones locales y no demuestran por sí solas la capacidad máxima.
- El cliente HTTP del proveedor y el cliente del webhook disponen de API no bloqueante.
- El generador de PDF es una función síncrona que mantiene ocupada la CPU mientras trabaja.
Cómo revisar tu respuesta
- `GET /shipping-quotes` se identifica como candidato claro a I/O asíncrono por sus 418 ms de espera frente a 7 ms de CPU.
- `POST /reports/monthly` no se recomienda como conversión directa a `async def`; sus 870 ms de CPU bloquearían el event loop.
- `POST /imports` se trata como carga mixta: el webhook puede ceder, pero los 312 ms de parseo siguen consumiendo CPU.
- La conclusión no promete una mejora exacta sin una prueba de carga posterior.
- La mejora se demuestra con la misma carga local y no con sleeps añadidos al test.
Evidencia, revisión y reinicio
- Implementación corregida de tres endpoints y traza temporal concurrente.
- Tests que detectan una llamada bloqueante dentro del event loop.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Eliminar el workspace temporal y volver a extraer el ZIP.