Analizo consultas, relaciones, índices, N+1 queries y acceso a datos para encontrar cuellos de botella reales, y entrego la latencia medida antes y después.
Por qué esto acaba costando más de lo que parece
La escena se repite: el panel del servidor está tranquilo —CPU baja, memoria de sobra— y aun así la petición tarda ocho segundos. Se compra una máquina más grande y mejora un diez por ciento. Se añade caché por encima y el problema reaparece en cuanto los datos cambian.
El servidor no está saturado: está esperando. Casi siempre porque una sola respuesta se construye con cientos o miles de idas y vueltas a la base de datos, porque falta un índice en la columna por la que se filtra, o porque el ORM trae la tabla entera para usar dos campos.
Nada de eso se ve leyendo el código. Se ve midiendo, que es lo que hace este servicio.
Cuatro situaciones en las que este servicio encaja
04 señalesY el servidor va sobrado de CPU y de memoria mientras tanto.
Lo que iba bien con mil registros dejó de ir con un millón.
Django, Prisma, Sequelize o Eloquent escribiendo SQL a tu espalda.
Cada pico de tráfico se resuelve pagando más servidor en vez de arreglar la causa.
De la consulta concreta al patrón de acceso que la genera
Cuatro fases, y lo que pasa en cada una
04 fasesSe identifican los endpoints lentos y se registra su latencia actual. Sin esa foto de partida no hay forma de demostrar después que algo mejoró.
Cada consulta crítica pasa por EXPLAIN ANALYZE y se revisa el código que la origina. El resultado es una causa concreta por cada espera, no una sospecha.
Se aplican los cambios: consultas reescritas, índices con su justificación, acceso a datos corregido. Cada cambio se mide por separado para saber cuánto aportó.
La misma medición del principio, con los mismos datos, y el informe con la diferencia. Si algo no mejoró, también aparece.
Lo que queda en tus manos cuando esto termina
Trabajo propio, con las cifras que se pueden comprobar
Un endpoint de listado que disparaba más de 9.000 consultas para construir una sola respuesta: el servidor no estaba saturado, estaba esperando. Reescribí el acceso a datos hasta resolverlo en una única consulta, con los índices que le faltaban.
Los tres casos, con su contexto completo, están en su propia sección. Ver todos los casos
Lo que se suele preguntar sobre este servicio
04 preguntasNo hace falta escribir en producción para medir. Con una copia de la base con volumen parecido, o con los planes de ejecución reales de las consultas, es suficiente. Los cambios se aplican donde tú decidas y cuando decidas.
No prometo un número antes de medir: quien lo hace está adivinando. Lo que sí entrego es la medición antes y después con los mismos datos. Si un cambio no aportó nada, aparece en el informe igual que los que sí.
Entonces el informe lo dice y señala dónde está: código de la aplicación, red, serialización o un servicio externo lento. La medición sirve precisamente para dejar de suponer.
Es donde tengo más profundidad y por eso da nombre al servicio. El patrón N+1 y los problemas de índices se parecen mucho en MySQL, pero si tu motor es otro lo hablamos antes.
Cuéntame tu caso. Respondo en menos de 24 h, de lunes a viernes.
Precio orientativo de partida. El alcance se fija tras ver el sistema.