PostgreSQL Performance
Si tu API tarda segundos y el servidor va sobrado, este es el servicio que empieza por medir.
Ver el servicioPostgreSQL · Rendimiento
De 62 segundos a 0,29 segundos
Un endpoint de listado tardaba más de un minuto en responder con el servidor tranquilo. La causa no estaba en el código que se leía, sino en cuántas veces preguntaba a la base de datos.
El punto de partida
Dónde estaba el sistema antes de tocarlo
El síntoma era el de casi todas las APIs lentas: una pantalla que tardaba tanto en cargar que la gente dejaba de usarla, y un panel de servidor que no acusaba nada. CPU baja, memoria de sobra, disco tranquilo. Nada que justificara un minuto de espera.
Cuando el servidor está ocioso y la respuesta tarda, el servidor no está trabajando: está esperando. Y casi siempre espera a la base de datos.
Qué estaba pasando
El problema real, no el que se ve desde fuera
La primera medición dio el número que explicaba todo: más de 9.000 consultas para construir una sola respuesta. Ninguna de ellas era lenta por separado —cada una tardaba fracciones de milisegundo— pero nueve mil idas y vueltas seguidas suman sesenta y dos segundos.
Es un patrón conocido y silencioso: la aplicación pide la lista, y después, por cada fila de esa lista, vuelve a preguntar por sus relaciones. En el código no se ve, porque en el código es un bucle de tres líneas sobre un objeto que parece tenerlo todo cargado. Solo se ve contando las consultas.
Qué hice
Las decisiones, en el orden en que se tomaron
04 pasos-
Medir antes de tocar nada
Registro de las consultas que dispara la petición y EXPLAIN ANALYZE de las que importan. Sin la foto inicial no hay forma de demostrar después que algo mejoró, y sin contar las consultas el problema es invisible.
-
Reescribir el acceso a datos
Las relaciones pasan a resolverse en la misma consulta que trae la lista, en lugar de una por fila. Nueve mil viajes se convierten en uno.
-
Añadir los índices que faltaban
Las columnas por las que se filtraba y se ordenaba no tenían índice, así que cada consulta recorría la tabla entera. Cada índice se justifica por su consulta y se pesa contra lo que cuesta al escribir.
-
Medir después, con los mismos datos
La misma petición, el mismo volumen, el mismo servidor: 0,29 segundos. La diferencia no se estima, se enseña.
El resultado
Lo que cambió, medido
- Latencia
- 62 s → 0,29 s
- Consultas
- 9.000+ → 1
- Mejora
- 213×
El mismo endpoint, sobre el mismo servidor y con los mismos datos, pasó de 62 segundos a 0,29: unas 213 veces más rápido. Las más de 9.000 consultas quedaron en una.
Lo que conviene retener no es la cifra, sino de dónde salió: no se cambió de servidor, no se añadió caché por encima y no se reescribió la aplicación. Se corrigió cómo pedía los datos.
Stack y conclusiones
Con qué se hizo y qué deja para el siguiente
- PostgreSQL
- EXPLAIN ANALYZE
- Índices
- Optimización de consultas
- Un servidor ocioso con respuestas lentas es casi siempre un problema de acceso a datos
- El N+1 no se ve leyendo el código: se ve contando consultas
- Escalar la máquina no arregla una espera, solo la hace más cara
- Sin medición antes y después, cualquier mejora es una opinión
¿Te suena tu propio sistema?
Cuéntame tu caso. Respondo en menos de 24 h, de lunes a viernes.