Laboratorio ejecutable · Bloque 1
EX-B1-07
Dónde se consume la latencia
Un `GET /v1/records/REC-204` tarda unos 306 ms. Soporte adjunta los tiempos acumulados de `curl`, el `X-Request-ID` de la respuesta y el log estructurado producido por la misma ejecución.
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 latenciaAPI lenta, script de medición, tests y huecos de instrumentación.
- Evidencia del incidenteComando `curl`, timings, header de correlación y log del servidor.
- Plantilla de diagnósticoCálculos de tramos, hallazgo principal y siguiente comprobación.
2. Escribe y prueba
- Ejecuta el baseline y mide al menos cinco peticiones con el script incluido.
- Implementa middleware que acepte o genere `X-Request-ID`, mida con reloj monotónico y añada `Server-Timing` sin registrar el body.
- Añade tests para correlación, formato de duración y presencia de headers también en una respuesta 404.
- Repite la medición, cruza un request ID con el log y localiza la espera dominante antes de proponer el siguiente experimento.
3. Demuestra el comportamiento
- Middleware y tests propios ejecutables.
- Una traza correlacionada cliente/servidor y tabla de cinco mediciones.
- Nota de incidente breve con hallazgo y siguiente comprobación.
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 instrumentar, ¿qué medición permitirá separar el tiempo observado por curl del trabajo medido dentro de la API?
Información que necesitas
$ curl --silent --output response.json --dump-header response.headers \
--write-out 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total} status=%{http_code}\n' \
'https://records.internal.example/v1/records/REC-204'
dns=0.018 connect=0.061 first_byte=0.302 total=0.306 status=200
$ grep -i x-request-id response.headers
X-Request-ID: req-7ac2
{"event":"request.complete","request_id":"req-7ac2","method":"GET","route":"/v1/records/{record_id}","status":200,"duration_ms":217,"db_ms":182,"serialize_ms":4}Comprueba estas tres cosas
- Calcula cada tramo restando los tiempos acumulados de `curl`.
- Usa `req-7ac2` para demostrar que el log pertenece a la misma petición.
- Compara `duration_ms` con `db_ms` y decide qué investigar después.
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Los hitos son acumulados
- La conexión adicional es `time_connect - time_namelookup`, no 61 + 18.
Pista 2 · Une ambas fuentes
- El mismo request ID aparece en la respuesta guardada y en el log estructurado.
Profundización opcional
Instrumentar una API con request ID y duración del servidor, medirla desde el cliente y localizar el tramo dominante con evidencia correlacionada.
Contexto adicional
- Los tiempos de `curl` son acumulados desde el comienzo; calcula un tramo restando el hito anterior.
- `time_starttransfer` incluye conexión, envío, trabajo del servidor y viaje del primer byte.
- No atribuyas automáticamente todo el tiempo restante a la red: compáralo con `duration_ms`.
Cómo revisar tu respuesta
- Los tiempos acumulados no se suman entre sí.
- DNS se calcula como 18 ms, conexión adicional como 43 ms y transferencia como 4 ms.
- El log se vincula por `req-7ac2`, no solo porque la ruta coincide.
- Los 182 ms de base de datos se reconocen como el componente medido dominante dentro de los 217 ms del servidor.
- La conclusión distingue medición de hipótesis y propone inspeccionar la consulta o su plan antes de optimizar otra capa.
- Los headers de observabilidad aparecen en éxito y error y no dependen de una variable global mutable.
Evidencia, revisión y reinicio
- Middleware de correlación y timing implementado y probado.
- Medición antes/después con request ID compartido entre respuesta y log.
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.