Por qué tu API va lenta: medir p95, consultas SQL y llamadas externas
Publicado el 2026-10-26 por frfrand
Investigar latencia real con logs, tracing y percentiles
«La API tarda 120 ms de promedio» puede sonar excelente, hasta que uno de cada veinte usuarios tarda varios segundos. El percentil 95 (p95) ayuda a ver esa cola lenta que el promedio esconde.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es Latencia p95 de una API y por qué importa
La latencia total de una API puede incluir conexión, autenticación, consultas SQL, llamadas a proveedores externos y serialización. El p95 indica el valor por debajo del cual cae aproximadamente el 95 % de las observaciones del conjunto medido. Hay que analizarlo por endpoint y ventana.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
# Medición puntual desde cliente; no reemplaza observabilidad
curl -sS -o /dev/null -w 'total=%{time_total} code=%{http_code}\n' https://api.ejemplo.com/health
# En backend registrar, sin datos sensibles:
# request_id, ruta_normalizada, status, duracion_ms
# Investigar queries con EXPLAIN ANALYZE en SELECTEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Medir p50, p95, p99, tasa de error y volumen de solicitudes por ruta.
- Registrar tiempos de SQL y de llamadas externas con request IDs sin exponer tokens.
- Reproducir la carga real: una ruta vacía
/healthno mide el checkout. - Atacar el componente más lento y comparar antes y después.
- Verificar que optimizar una ruta no haya empeorado consumo de memoria o escritura.
Después de cada paso, verificar un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprobar cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una web de alquileres responde rápido al listar propiedades, pero confirmar reservas tarda 2 segundos por una API externa de pago. Cambiar de VPS no arregla esa llamada; puede convenir desacoplar trabajos y controlar timeouts.
Si esa aplicación tiene varios clientes, separar contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No comparar p95 calculado con 10 solicitudes con otro de 100.000 y concluir que el segundo es peor. Requiere una ventana, tráfico y distribución adecuados.
Una configuración con buenos valores predeterminados ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriban datos o disparen acciones, contempla reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
Con ArduMaker puedes administrar API y PostgreSQL en VPS, y combinar registros y métricas para decidir si optimizar SQL, cambiar la concurrencia o ampliar recursos.
Con ArduMaker puedes alojar el backend en un VPS, desplegar desde Git, configurar un dominio HTTPS y utilizar herramientas de bases de datos, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría solo «funciona/no funciona». También revisaría el consumo de recursos, los errores, los tiempos de respuesta o el gasto de API, según la funcionalidad. Define una medida de éxito antes del cambio y compárala con el mismo escenario después.
Si un dato parece extraño, comprueba la muestra y la ventana temporal. Un promedio puede ocultar casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resuelve el problema con una arquitectura simple y mide el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitas timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registra eventos importantes, separa permisos y conserva un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabes detectar un error, limitar sus efectos y recuperarte.