Cuando tu API es lenta, decir "está lenta" no alcanza. Necesitas saber dónde se está gastando el tiempo. ¿Es la resolución DNS? ¿El handshake TLS? ¿El procesamiento del servidor? ¿La descarga de la respuesta?

Esta guía desglosa cada fase de una solicitud API, explica las métricas que importan y muestra cómo usarlas para diagnosticar problemas reales.

Anatomía de una Solicitud API

Cada solicitud HTTP pasa por una serie de fases antes de que llegue un solo byte de respuesta:

Cliente → DNS Lookup → TCP Connect → TLS Handshake → Envío → Procesamiento → TTFB → Transferencia → Fin

Cada fase tiene su propia métrica de tiempo, y cada una puede ser el cuello de botella.

DNS Lookup Time: El Cuello de Botella Silencioso

El DNS lookup mide cuánto tarda resolver un nombre de dominio a una dirección IP. Ocurre antes de que se establezca cualquier conexión.

Un lookup típico toma 10-50ms con entradas cacheadas. Cualquier valor consistentemente arriba de 200ms es una señal de alerta.

Causas de DNS Lento

  • Proveedor DNS distante: Si tu DNS autoritativo está en una sola región, los clientes lejanos pagan penalización de round-trip.
  • TTL bajo: Un TTL de 60 segundos fuerza re-consultas cada minuto. TTLs de 300-3600 segundos son más prácticos.
  • Sin anycast: Proveedores DNS sin anycast sirven todas las consultas desde pocas ubicaciones.
  • Problemas de propagación: Después de un cambio DNS, diferentes resolvers tienen valores cacheados distintos.

Cómo Diagnosticar

$ dig api.ejemplo.com +stats
;; Query time: 23 msec

Si el DNS lookup es consistentemente alto, la solución suele ser cambiar a un proveedor DNS anycast (Cloudflare, Route 53, Google Cloud DNS) y configurar TTLs adecuados.

TLS Handshake: El Costo de la Encriptación

El handshake TLS establece una conexión segura encriptada. Es obligatorio para cualquier API HTTPS y agrega latencia medible.

Un handshake TLS 1.3 típicamente agrega 50-100ms (un round trip). TLS 1.2 requiere dos round trips, agregando 100-200ms.

Causas de TLS Lento

  • Cadenas de certificados largas: Si tu servidor envía 4+ certificados, el cliente debe verificar cada uno.
  • Certificados intermedios faltantes: El cliente debe buscarlos por separado, agregando cientos de milisegundos.
  • OCSP stapling deshabilitado: Sin OCSP stapling, el cliente hace una solicitud separada para verificar revocación.
  • Versiones TLS antiguas: TLS 1.2 requiere dos round trips vs. uno para TLS 1.3.

Con HTTP/2, múltiples solicitudes se multiplexan sobre una sola conexión, amortizando el costo del handshake. Por eso la reutilización de conexiones es crítica.

Time to First Byte (TTFB): La Métrica Más Importante

TTFB mide el tiempo entre enviar la solicitud y recibir el primer byte de respuesta. Aísla el tiempo de procesamiento del servidor del overhead de red.

Qué es Normal

  • Menos de 100ms: Excelente. Probablemente sirviendo desde caché.
  • 100-300ms: Normal para endpoints con consultas a base de datos.
  • 300-500ms: Aceptable para operaciones complejas.
  • Más de 500ms: Investigar. Generalmente indica consultas lentas o dependencias externas no responsivas.

TTFB vs. Tiempo de Respuesta Total

    Tiempo Total = DNS + TCP + TLS + Envio + TTFB + Descarga
TTFB = Solo procesamiento del servidor

Dos APIs pueden tener TTFB idéntico pero tiempos totales muy diferentes. Monitorear ambas métricas por separado es esencial para un diagnóstico preciso.

P50, P95, P99: Por Qué los Promedios Mienten

Si tu dashboard solo muestra el tiempo de respuesta promedio, estás perdiendo información crucial. Los promedios ocultan el dolor de tus usuarios más afectados.

Ejemplo Concreto

Una API con estos tiempos para 100 solicitudes:

  • 90 solicitudes: 80-120ms
  • 7 solicitudes: 400-600ms
  • 3 solicitudes: 2000-4000ms

El promedio es ~230ms. Se ve bien. Pero P50 es 100ms, P95 es 550ms, y P99 es 3200ms. El 1% de usuarios espera 32 veces más que el usuario típico.

Causas de Latencia en la Cola

  • Agotamiento del pool de conexiones: Algunas solicitudes esperan en la cola por una conexión disponible.
  • Pausas de garbage collection: En JVM o .NET, el GC puede congelar todos los hilos.
  • Cold starts: Funciones serverless inicializan nuevas instancias de forma impredecible.
  • Contención de locks: Solicitudes concurrentes compitiendo por el mismo recurso.

Cómo Nurbak Monitorea Estas Métricas

Nurbak captura todas las métricas de este artículo automáticamente en cada health check. Sin SDK, sin cambios de código, sin agentes. Registras tu endpoint y Nurbak comienza a monitorear.

Cada check registra: DNS Lookup Time, TCP Connection Time, TLS Handshake Time, TTFB, Total Response Time y HTTP Status Code. Los health checks corren desde hasta 4 regiones globales: Virginia, São Paulo, París y Tokio.

El dashboard muestra P50, P95 y P99 a lo largo del tiempo, permitiendo detectar tendencias antes de que se conviertan en incidentes.

Ejemplos de Debugging Real

TTFB alto, todo lo demás normal

DNS: 25ms ✓  |  TLS: 60ms ✓  |  TTFB: 1800ms ✗  |  Total: 1920ms

Diagnóstico: El servidor es lento. Buscar consultas lentas a base de datos, patrones N+1, o llamadas sincrónicas a APIs externas.

DNS alto, todo lo demás normal

DNS: 450ms ✗  |  TLS: 55ms ✓  |  TTFB: 90ms ✓  |  Total: 630ms

Diagnóstico: La resolución DNS toma medio segundo. Verificar TTL, considerar proveedor DNS anycast.

TLS alto solo desde algunas regiones

Virginia: TLS 65ms ✓  |  París: TLS 280ms ✗  |  Tokio: TLS 310ms ✗

Diagnóstico: Problema de cadena de certificados o configuración TLS. Habilitar OCSP stapling, verificar TLS 1.3, considerar CDN para terminar TLS más cerca del cliente.

Resumen

El rendimiento de una API no es un solo número. Es una serie de fases — DNS, TCP, TLS, TTFB, transferencia — cada una con sus propios modos de fallo. Monitorear solo el tiempo total es como ver solo el marcador final: sabes que perdiste, pero no por qué.

Desglosa tus métricas. Rastrea percentiles, no promedios. Monitorea desde múltiples regiones. Nurbak captura todo esto automáticamente. Crea una cuenta gratuita y comienza a ver la imagen completa del rendimiento de tu API.