La lección anterior cerró con una promesa: CicloUrbana está en producción y llega sola, y a partir de ahora vamos a verla funcionar y a hacer que vaya rápido. Este es el primer paso, y conviene empezar deshaciendo un malentendido: ajustar el rendimiento no consiste en aplicar trucos. No es añadir una caché, subir el pool de conexiones a 100 ni cambiar el recolector de basura porque en un artículo decían que era más rápido. Todo eso son palancas, y sin un método detrás son tres formas distintas de mover un número al azar.

El método es corto y no se salta ningún paso: medir, encontrar el cuello de botella, corregir una sola cosa, volver a medir. Esta lección lo recorre entero sobre la red de Ribalta. Veremos por qué la media de latencia miente y qué mirar en su lugar, cómo establecer una línea base con una prueba de carga que reproduzca la hora punta, dos leyes que dicen dónde merece la pena esforzarse, y después el recorrido priorizado por los lugares donde de verdad se va el tiempo: la base de datos primero —el N+1 y los índices—, luego el pool de conexiones, la JVM, los hilos y la red. Terminaremos con un caso completo: un endpoint que tarda 2,4 segundos en p95 y acaba tardando 90 milisegundos.

1. El método: nunca optimizar sin medir
2. Objetivos: SLI, SLO y por qué la media miente
3. La línea base: la prueba de carga
4. Un script de k6 para la hora punta de Ribalta
5. Leer los resultados de la prueba
6. Dos leyes prácticas: Little y Amdahl
7. Dónde se va el tiempo en una aplicación Spring Boot
8. La base de datos (I): detectar el N+1
9. La base de datos (II): índices y EXPLAIN ANALYZE
10. La base de datos (III): paginación, proyecciones y lotes
11. HikariCP: dimensionar el pool con criterio
12. La JVM: memoria, recolector y pausas
13. Hilos: Tomcat, el pool y los hilos virtuales
14. La red: compresión y tamaño de la respuesta
15. Perfilado: async-profiler, JFR y volcados
16. Caso práctico: el endpoint de estaciones
17. Errores Comunes y Consejos
18. Ejercicios

Hay una frase de Donald Knuth que todo el mundo cita a medias. La completa dice: «los programadores gastan una cantidad enorme de tiempo preocupándose por la velocidad de partes no críticas, y esos intentos tienen un impacto muy negativo cuando se consideran la depuración y el mantenimiento. Deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97 % del tiempo: la optimización prematura es la raíz de todos los males. Aun así, no deberíamos dejar pasar nuestras oportunidades en ese 3 % crítico.»

Lo importante es el final: existe un 3 % crítico y hay que encontrarlo. El error no es optimizar, es optimizar a ciegas. Y la intuición sobre dónde está ese 3 % es notoriamente mala: casi todos los desarrolladores apuestan por su propio código Java, cuando en una aplicación como CicloUrbana el tiempo está casi siempre esperando a la base de datos o a un servicio remoto.

El ciclo de trabajo es este:

Tres reglas gobiernan ese ciclo. Un cambio cada vez: si tocas el pool, la caché y el índice a la vez y mejora, no sabes cuál sirvió ni cuál está empeorando otra cosa —y en CicloUrbana esa disciplina es barata, porque cada cambio es un despliegue automático (08-05)—. Parar cuando se cumple el objetivo: sin criterio de parada el ajuste no termina nunca y acaba añadiendo complejidad que nadie necesita; «rápido» no es un objetivo, «p95 por debajo de 300 ms con 200 usuarios concurrentes» sí lo es. Y medir donde importa: un System.currentTimeMillis() alrededor de un método en tu portátil, con la base de datos vacía y sin concurrencia, no dice nada sobre Ribalta a las ocho de la mañana.

Antes de medir hay que decidir qué se mide y qué valor es aceptable:

La elección del estadístico no es un detalle: es la decisión más importante de todo el capítulo. Supongamos 1.000 peticiones al endpoint de inicio de alquiler en una hora punta de Ribalta:

La media es (900×40 + 80×300 + 20×3000) / 1000 = 120 ms. Un número excelente que se puede llevar a una reunión sin sonrojarse. Ahora los percentiles: ordenadas las 1.000 latencias, la posición 950 (p95) cae en el grupo de 300 ms, y la posición 990 (p99) cae en el grupo de 3.000 ms.

p50 = 40 ms · media = 120 ms · p95 = 300 ms · p99 = 3.000 ms

Los mismos datos cuentan dos historias opuestas. Y la que importa es la segunda: 20 de cada 1.000 ciudadanos esperan tres segundos mirando la pantalla del móvil delante de una bicicleta. En una hora punta con 12.000 alquileres, son 240 personas cada mañana. La media los ha escondido porque promedia sobre una distribución con cola larga, que es exactamente la forma que tienen todas las distribuciones de latencia reales.

Cuatro reglas prácticas. La media nunca es el SLO: sirve, como mucho, para detectar una regresión grosera. p95 describe la experiencia típica mala y p99 o p99,9 la peor, y cuanto más crítico es el servicio más a la derecha hay que mirar. Los percentiles no se promedian: la media de los p95 de tres instancias no es el p95 del conjunto, algo con consecuencias técnicas muy concretas que veremos en 09-03 con los histogramas. Y latencia y disponibilidad se miran juntas, porque un endpoint que devuelve 500 en 5 ms tiene un p99 magnífico.

Sin línea base no hay mejora, solo sensación de mejora. Una prueba de carga somete a la aplicación a un tráfico controlado y reproducible, para poder comparar el antes y el después con el mismo patrón.

Elegimos k6: el escenario vive junto al código, se ejecuta en la canalización de 08-05 y no necesita una máquina potente para generar 500 usuarios virtuales. Tres advertencias antes del script: no pruebes contra producción sin acordarlo —se prueba contra pre (07-02) y con datos de volumen realista, porque una base con 12 estaciones y 30 alquileres no revela nada—; el generador no puede ser el cuello de botella, así que si k6 corre en el mismo portátil que la aplicación estás midiendo el portátil; y calienta la JVM, porque los primeros segundos son código interpretado y pool frío, y se descartan.

El escenario reproduce lo que ocurre entre las 7:45 y las 9:15 en Ribalta: mucha gente consulta estaciones cercanas, una parte inicia un alquiler y, unos minutos después, lo finaliza.

Qué hace cada pieza y por qué. stages define la forma de la carga, y la rampa inicial no es cortesía: sin ella se mide la JVM interpretando bytecode y HikariCP abriendo conexiones, no el estado estacionario —la meseta es la única parte cuyos números valen—. thresholds convierte el SLO en una condición de fallo: si no se cumple, k6 sale con código distinto de cero y la canalización de 08-05 se pone en rojo, de modo que el rendimiento deja de ser una opinión y pasa a ser una prueba. setup() se ejecuta una vez y comparte el token con todos los usuarios virtuales, para no medir el coste del login en cada iteración. sleep() es imprescindible: sin pausas no se simulan 200 ciudadanos, se simula un ataque; el tiempo de reflexión es lo que hace que la concurrencia del escenario se parezca a la real. Y las métricas propias (Trend, Rate) separan el SLO de negocio —iniciar un alquiler— del agregado de todas las peticiones.

Se ejecuta así:

Cómo se interpreta, en orden. ¿Falló algún umbral? Sí: el p95 global es 1,19 s frente a los 300 ms del SLO, así que la prueba ha hecho su trabajo. ¿Hay errores? Un 0,71 %, por debajo del umbral del 1 %, pero no es ruido y hay que mirar de qué tipo son: un 500 es un fallo, mientras que un 409 puede ser el índice único parcial de 04-08 rechazando un segundo alquiler del mismo usuario, que es correcto. ¿Media contra percentiles? avg=214ms frente a p(95)=1.19s y max=4.8s: la cola larga del apartado 2, exactamente. ¿Qué operación concreta? alquiler_inicio_ms tiene p95 de 2,41 s con mediana de 210 ms, luego el problema no está repartido: está en un punto y solo bajo carga —una operación con mediana buena y p95 diez veces peor casi siempre espera por un recurso compartido: una conexión del pool, un bloqueo de fila o una pausa de GC—. ¿Escala? 112 peticiones por segundo con 200 usuarios virtuales; si al doblar los usuarios el rendimiento no sube y la latencia sí, se ha alcanzado la saturación y hay un recurso limitado detrás.

Esa es la línea base. Se guarda en el repositorio con la fecha y la versión desplegada, porque la única forma honesta de afirmar «esto va más rápido» es comparar contra ella.

La ley de Little relaciona tres magnitudes en cualquier sistema estable:

Con los números de la prueba: λ = 112 pet/s, W = 0,214 s de media, luego L = 24 peticiones dentro del sistema a la vez. Ese número es oro:

• Si hay 24 peticiones concurrentes y el pool de HikariCP tiene 10 conexiones, hay peticiones esperando conexión. Ahí está el candidato.
• Si Tomcat tiene 200 hilos y solo 24 se usan, subir los hilos no arregla nada. Es el error más frecuente del ajuste por intuición.
• Al revés: si el objetivo es 300 peticiones por segundo con 200 ms de latencia, hará falta soportar L = 60 peticiones simultáneas. La ley te dice el requisito antes de probar.

La ley de Amdahl dice cuánto puede mejorar el conjunto al acelerar una parte:

donde P es la fracción del tiempo que ocupa la parte optimizada y S cuánto se acelera. Dos casos de CicloUrbana:

La lectura es demoledora: hacer diez veces más rápida la serialización mejora el conjunto un 5 %. Media semana de trabajo para una ganancia que no se ve. Por eso el primer paso siempre es averiguar el reparto del tiempo, y por eso la tabla del apartado siguiente está ordenada.

Reparto típico en una aplicación de gestión como CicloUrbana, con el orden en que conviene buscar:

La conclusión práctica: empieza siempre por la base de datos y baja por la lista. Y no pases al nivel siguiente hasta haber agotado el anterior, porque el orden refleja la ley de Amdahl aplicada al caso medio.

Recuperamos el problema de 04-04 con la formulación operativa: el número de consultas de un endpoint debe ser constante, no proporcional al número de resultados. Primero, verlo. En dev basta con abrir el SQL:

El resumen de generate_statistics es el dato clave:

201 sentencias para listar 200 estaciones. No hace falta más diagnóstico.

Ver el SQL a mano no escala: en cuanto el endpoint es complejo, nadie cuenta líneas. La solución es un contador de consultas por petición, con datasource-proxy:

Se envuelve el DataSource en un BeanPostProcessor anotado con @Profile({"dev","test"}) —nunca en producción, porque intercepta cada consulta— que devuelve ProxyDataSourceBuilder.create(ds).name("ciclourbana").countQuery().logSlowQueryBySlf4j(200, MILLISECONDS).build(): countQuery() acumula el recuento por hilo y logSlowQueryBySlf4j avisa de las consultas que pasan de 200 ms. Encima, un filtro escribe al final de cada petición cuántas consultas se ejecutaron —y como el FiltroTraza de 03-06 ya ha puesto el trazaId en el MDC, la línea es directamente correlacionable con el resto del log:

Con esto, un endpoint que se degrada avisa solo en cuanto alguien introduce un getBicicletas() dentro de un bucle. Y la técnica llega hasta las pruebas: en un @DataJpaTest (06-04) se puede afirmar assertThat(contador.getTotal()).isEqualTo(1), convirtiendo «no hay N+1» en una prueba de regresión de verdad.

La corrección ya la conocemos de 04-04 y 04-06: @EntityGraph(attributePaths = "bicicletas") o JOIN FETCH cuando se necesitan las entidades, @BatchSize cuando la colección se pagina, y —a menudo la mejor— una proyección que haga contar a la base de datos y no traiga entidades en absoluto.

Un índice es una estructura auxiliar que evita leer la tabla entera. La pregunta no es «¿pongo un índice?» sino «¿qué columnas filtran y ordenan mis consultas reales?». Y la respuesta la da PostgreSQL, no la intuición.

La consulta del historial del ciudadano:

Antes de tocar nada, con 3,2 millones de filas:

Cómo se lee, de dentro hacia fuera:

Existía ya idx_alquileres_usuario de 04-08, pero el planificador lo descarta: con 27.000 alquileres de ese usuario, saltar del índice a la tabla 27.000 veces le sale más caro que barrerla. La solución es un índice compuesto que cubra el filtro y el orden:

De 812 ms a 0,08 ms: casi diez mil veces. No hay ninguna optimización de código Java capaz de acercarse a eso, y ese es el argumento de toda la lección.

El orden de las columnas del índice compuesto no es arbitrario. La regla, en este orden: primero las columnas de igualdad (usuario_id, estado), después las de rango u orden (inicio DESC). Un índice (usuario_id, estado, inicio) sirve para consultar por usuario_id, por usuario_id + estado y por los tres; no sirve para consultar solo por estado. Es el principio del prefijo izquierdo, y explica por qué un índice bien pensado suele hacer innecesarios dos o tres.

Índices parciales. Cuando solo interesa un subconjunto:

Ocupa kilobytes en lugar de cientos de megabytes y es el mismo mecanismo del uk_alquileres_usuario_en_curso de 04-08.

El coste de indexar de más. Un índice no es gratis: ocupa espacio, cada INSERT, UPDATE y DELETE debe actualizarlo, y empeora el trabajo del planificador. Una tabla con doce índices puede tardar el triple en escribir. Para saber cuáles sobran:

idx_scan = 0 tras semanas en producción significa que ese índice solo cuesta. Y para encontrar las consultas caras, la extensión pg_stat_statements ordenada por total_exec_time responde a la pregunta «qué consulta consume el 40 % del tiempo de base de datos».

El OFFSET grande. Pageable genera LIMIT 20 OFFSET 200000, y PostgreSQL debe producir y descartar 200.000 filas antes de devolver 20. La página 1 vuela; la página 10.000 tarda segundos. Para listados profundos —el histórico completo de alquileres, una exportación— se usa paginación por keyset:

El cliente envía la última fila vista en lugar de un número de página. La consulta usa el índice para posicionarse en lugar de contar, y el coste es constante en cualquier profundidad. Sus límites: no permite saltar a la página 500 ni mostrar el total —y ese count(*) de cada Page es, muchas veces, más caro que la consulta de datos: por eso existe Slice, que lo evita.

Proyecciones frente a entidades (04-06). Cargar la entidad completa trae todas las columnas, crea objetos gestionados en el contexto de persistencia y obliga a Hibernate a hacer dirty checking sobre cada uno al confirmar:

La regla de CicloUrbana: los endpoints de solo lectura devuelven proyecciones. Es simultáneamente más rápido y más seguro.

readOnly y lotes. @Transactional(readOnly = true) (04-07) hace que Hibernate use FlushMode.MANUAL y no guarde el estado original para comparar: menos memoria y menos CPU en cada lectura. Y para las escrituras masivas del importador nocturno:

Insertar 10.000 filas pasa de 10.000 viajes de red a 200. Requisito: el generador de identificadores no puede ser IDENTITY, porque obliga a ejecutar cada INSERT por separado para conocer la clave; por eso CicloUrbana usa secuencias con allocationSize = 50 desde 04-03.

La intuición dice «más conexiones, más rendimiento». Es falsa, y el motivo es que una conexión ocupada es un núcleo de CPU y un disco de la base de datos trabajando. Cuando hay más conexiones activas que capacidad real, el servidor de base de datos dedica tiempo a cambiar de contexto y a competir por bloqueos: el rendimiento baja y la latencia sube.

La fórmula que documenta el propio HikariCP:

La instancia de PostgreSQL de CicloUrbana tiene 4 núcleos y almacenamiento SSD en red (1 «disco» efectivo): 4 × 2 + 1 = 9, redondeado a 10. Sí, diez conexiones sirven 112 peticiones por segundo: por la ley de Little, si una consulta dura 5 ms, cada conexión puede atender 200 consultas por segundo.

Cuatro detalles con consecuencias. minimum-idle igual a maximum-pool-size: un pool elástico ahorra unos recursos irrelevantes y añade la latencia de un handshake TCP más autenticación justo cuando llega el pico. connection-timeout: 3000: si no hay conexión en 3 segundos se lanza excepción, mientras que un valor de 30 s convierte una degradación en una cola que acaba consumiendo los 200 hilos de Tomcat —así es como un problema de base de datos derriba la aplicación entera—. leak-detection-threshold avisa de una conexión retenida más de 20 s, síntoma clásico de una llamada HTTP dentro de una transacción. Y max-lifetime debe ser menor que el tiempo de cierre del lado servidor, o el pool entregará conexiones muertas.

Detectar la espera es lo que decide si el pool está mal dimensionado. La métrica hikaricp.connections.pending (09-03) mide cuántos hilos esperan y hikaricp.connections.acquire cuánto tardan. Si pending es persistentemente mayor que cero hay dos causas posibles y solo una se arregla subiendo el pool: si las consultas son lentas o las transacciones larguísimas, arregla eso y no el pool; si la base de datos va sobrada y la concurrencia es real, sube el pool con moderación y vuelve a medir.

Memoria en contenedor (07-04). La JVM moderna detecta los límites del cgroup, pero por defecto reserva solo el 25 % de la memoria disponible para el heap. En un contenedor de 1 GB eso son 256 MB, y el resto se desperdicia:

El 75 % —no el 100 %— deja sitio para lo que no es heap: metaespacio, pilas de hilos, búferes directos y la propia JVM. Si el heap ocupa todo el límite del contenedor, el proceso muere con OOMKilled (código 137) sin dejar ni una excepción, y el restartPolicy de Kubernetes lo reinicia en bucle. +ExitOnOutOfMemoryError es preferible a arrastrarse: una instancia con la memoria agotada responde mal y sigue recibiendo tráfico; muerta, la sonda de 07-01 la saca del balanceador.

Elegir recolector:

El criterio real: no cambies de recolector hasta haber comprobado, en los logs de GC, que las pausas explican tu p99. Con 2 GB de heap y G1, las pausas de CicloUrbana son de 15-40 ms; el p95 de 1,19 s no viene de ahí.

Leer los logs de GC:

Qué mirar. La notación 1204M->318M(2048M) es antes → después (total): recuperó 886 MB, luego está sano. En cambio 1902M->1841M recuperó 61 MB de 1,9 GB, es decir, la memoria ya no baja —fuga o heap insuficiente—, que es exactamente el síntoma que anticipaba el cierre de 08-05. La Pause Full de 1,8 s detiene todos los hilos y una sola basta para explicar un p99 desastroso; si se repiten, se acerca un OutOfMemoryError. Y la frecuencia importa tanto como la duración: pausas jóvenes cortas cada pocos segundos son lo normal, pero cada 200 ms significa que se genera basura a manos llenas, casi siempre por cargar entidades que no se necesitan —el apartado 10 otra vez—.

La relación entre ambos pools es la fuente de un malentendido caro. Con 200 hilos de Tomcat y 10 conexiones de HikariCP, hasta 190 hilos pueden estar bloqueados esperando una conexión. Eso no es un fallo de diseño: es un embudo deliberado que protege a la base de datos. Lo que sí es un fallo es no acotar la espera —de ahí el connection-timeout: 3000 del apartado 11—.

Y subir threads.max a 800 casi nunca ayuda: si el cuello está en las 10 conexiones, los 600 hilos nuevos solo añaden 600 pilas de 1 MB y más cambios de contexto. La ley de Little dice cuántos hilos hacen falta de verdad: hilos ≈ λ × W; con 112 pet/s y 214 ms, unos 24.

Hilos virtuales (07-03), en Java 21 y Spring Boot 3.2+:

Cada petición se atiende en un hilo virtual, que al bloquearse en E/S libera el hilo de plataforma en lugar de ocuparlo. Para una aplicación como CicloUrbana —bloqueante y con mucha espera de base de datos— es la forma más barata de sostener alta concurrencia sin pila reactiva. Con dos advertencias que ya vimos: synchronized alrededor de una operación bloqueante fija el hilo virtual y anula la ventaja, y los ThreadLocal —el MDC del FiltroTraza, el SecurityContext— siguen funcionando, pero ya no hay un pool acotado que limite la concurrencia: el límite pasa a ser el pool de conexiones, así que su connection-timeout se vuelve todavía más importante.

El tiempo que el ciudadano percibe incluye la transferencia. Un listado de 200 estaciones en JSON son unos 180 KB; sobre una red móvil de Ribalta, medio segundo por sí solo.

Con JSON, gzip reduce entre un 70 % y un 90 % porque el formato repite las claves en cada elemento: 180 KB pasan a unos 20 KB. El coste es CPU del servidor; si hay un proxy o un ALB delante (08-03), a menudo es mejor que comprima él.

Pero la mejor compresión es no enviar el dato. Aquí es donde los DTOs de 03-05 dejan de ser una cuestión de diseño y se convierten en rendimiento: EstacionResponse publica seis campos en lugar de volcar la entidad con sus auditorías, su version y su colección de bicicletas. Menos bytes serializados, menos CPU, menos red y menos memoria. Tres reglas: pagina siempre los listados (nunca un findAll() sin Pageable), no anides colecciones completas en la respuesta —enlaza a un subrecurso—, y usa ETag (03-03) para que el cliente que ya tiene el dato reciba un 304 Not Modified de doscientos bytes.

Cuando la base de datos ya está limpia y el tiempo sigue yéndose a algún sitio, toca perfilar.

Cómo se lee un gráfico de llama. El eje horizontal no es tiempo: es la proporción de muestras. Cada barra es un método y encima están los métodos a los que llama. Se lee de abajo arriba buscando mesetas anchas: una barra ancha significa que ese método estaba en la pila en muchas muestras. Si la meseta está arriba del todo, ese método consume CPU por sí mismo; si es ancha pero con torres encima, el coste está en lo que llama. En CicloUrbana, un perfilado típico muestra una meseta ancha bajo PgConnection.execSQLQuery —esperando a la base de datos, que es lo esperado— y, si algo va mal en el código, una torre inesperada bajo ObjectMapper.writeValue o bajo un equals de entidades.

Y el uso más rentable de /actuator/threaddump: con la aplicación lenta, se descarga y se cuentan los hilos por estado. Cincuenta hilos http-nio-8080-exec-* en WAITING sobre HikariPool.getConnection es un diagnóstico cerrado, sin necesidad de perfilar nada.

Síntoma. GET /api/v1/estaciones?page=0&size=20 tiene un p95 de 2,4 s en la prueba de carga. La mediana es 210 ms.

Paso 1 — medir. El FiltroContadorConsultas del apartado 8 escribe en el log de pre:

43 consultas para 20 estaciones: 1 + 20 + 20 + 2. El patrón es inequívoco.

Paso 2 — localizar. El código:

Dos N+1 encadenados. Y contarDisponibles ejecuta select count(*) from bicicletas where estacion_id = ? and estado = 'DISPONIBLE', cuyo EXPLAIN ANALYZE revela un Seq Scan: idx_bicicletas_estado existe, pero por sí solo no filtra bien.

Paso 3 — corregir. Dos cambios, uno por causa. Una proyección que hace contar a la base de datos en una sola consulta:

Y el índice compuesto que sostiene esa subconsulta:

Igualdad primero, y con las dos columnas del filtro el índice cubre la consulta: PostgreSQL cuenta sin tocar la tabla.

Paso 4 — volver a medir. Misma prueba de k6, misma máquina, mismos datos:

Cuatro observaciones valen más que los números. No se ha añadido ni una caché ni una máquina: se ha quitado trabajo innecesario. pending bajó a cero solo, lo que demuestra que el pool no estaba mal dimensionado sino retenido por consultas de más —subirlo a 50 habría escondido el problema y castigado a la base de datos—. El p95 mejoró más que la mediana (26× frente a 7,5×), que es lo típico cuando la causa era espera por un recurso compartido. Y el SLO del apartado 2 —p95 < 300 ms— se cumple, así que se para.

Este era el caso fácil: había trabajo desperdiciado. Cuando ya no lo hay y la consulta es mínima y está indexada, pero se repite mil veces por minuto con el mismo resultado, la siguiente palanca es distinta: no ejecutarla. Eso es la caché, y es la lección siguiente.

Optimizar sin línea base y usar la media como objetivo. Sin un número anterior, «va más rápido» es una impresión: guarda el resultado de k6 con la fecha y la versión en el repositorio. Y la media esconde exactamente a los usuarios peor tratados, así que el SLO se escribe en p95 y p99.

Cambiar varias cosas a la vez. Si mejoras el índice, subes el pool y activas la compresión en el mismo despliegue, no sabrás cuál valió ni podrás revertir el que sobra.

Subir el pool de conexiones como primera medida. Casi siempre empeora: traslada la congestión de tu aplicación a la base de datos, donde es más difícil de ver y afecta a todo el mundo.

Medir en el portátil con datos de juguete. Un Seq Scan sobre 40 filas es instantáneo. Los problemas de rendimiento son problemas de volumen y de concurrencia, y se reproducen en pre con datos realistas.

Dejar org.hibernate.SQL: DEBUG o datasource-proxy en producción. Ambos añaden coste por consulta y llenan el disco: van bajo @Profile({"dev","test"}), y si hace falta ver SQL en producción se sube el nivel en caliente con /actuator/loggers (07-01) y se baja después.

Confundir un Full GC con «hay que subir la memoria». A veces sí; muchas veces es que se cargan entidades que no se necesitan. Mira primero el apartado 10.

Consejo: pon un límite de consultas por petición en las pruebas, con un assertThat(contador.getTotal()).isLessThanOrEqualTo(3) en un @DataJpaTest: es la única forma de que un N+1 no vuelva dentro de tres meses. Ejecuta además la prueba de carga en la canalización nocturna, porque con thresholds una regresión se detecta el día que se introduce y no el día que llama el ayuntamiento. Y EXPLAIN ANALYZE antes de crear un índice, con una revisión de pg_stat_user_indexes cada trimestre para borrar los que nadie usa.

Tras un despliegue, la operación de CicloUrbana observa: p50 de POST /api/v1/alquileres = 45 ms (sin cambios), p99 = 4,2 s (antes 300 ms), CPU de la aplicación al 20 %, CPU de la base de datos al 25 %, hikaricp.connections.pending con picos de 60, ningún Full GC, y el log del contador de consultas dice «3 consultas en 4.100 ms». Formula la hipótesis más probable, di qué comprobarías para confirmarla y qué no harías.

El cuadro de mando del ayuntamiento ejecuta esta consulta cada minuto y tarda 1,8 s:

EXPLAIN ANALYZE muestra Seq Scan on alquileres con Rows Removed by Filter: 3198412. Propón el índice, justifica el orden de las columnas, decide si debe ser parcial y estima el efecto.

CicloUrbana debe soportar 400 peticiones por segundo con p95 < 250 ms. La latencia media medida es 180 ms, de los cuales 120 ms son base de datos (dos consultas de 60 ms). El servidor de PostgreSQL tiene 8 núcleos y SSD. Calcula la concurrencia necesaria, dimensiona el pool de HikariCP y los hilos de Tomcat, y di si el sistema puede cumplir el objetivo o dónde se romperá primero.

Solución 1.

Hipótesis: espera por conexión del pool, no lentitud de la aplicación. Las señales encajan una a una: la mediana intacta indica que el camino rápido no ha cambiado; el p99 disparado con CPU baja en ambos lados descarta saturación de cálculo; pending con picos de 60 dice literalmente que 60 hilos esperan conexión; «3 consultas en 4.100 ms» es la firma exacta —pocas consultas, mucho tiempo—, porque el tiempo no se va ejecutando SQL sino esperando para poder ejecutarlo; y la ausencia de Full GC descarta pausas de memoria.

Causa más probable: algo retiene conexiones más tiempo del debido. Los dos sospechosos habituales: una llamada HTTP dentro de una transacción —muy probable aquí, porque el despliegue tocó el cobro y la pasarela de 07-06 puede tardar segundos— o una transacción alargada por trabajo que no necesita la base de datos.

Cómo confirmarlo: con /actuator/threaddump durante un pico, buscando hilos http-nio-* en WAITING sobre HikariPool.getConnection y —sobre todo— hilos que ya tienen conexión y están bloqueados en un socket de la pasarela; activando leak-detection-threshold: 20000, cuya traza de pila señala el método culpable; mirando las métricas de Resilience4j (07-06), porque si la latencia de la pasarela subió a la vez el diagnóstico está cerrado; y observando hikaricp.connections.usage, que mide cuánto se retiene cada conexión.

Qué NO haría: subir maximum-pool-size. Con la CPU de la base de datos al 25 % el problema no es falta de capacidad, y más conexiones retenidas por llamadas remotas solo alargan la agonía. Tampoco subir los hilos de Tomcat: crearía más hilos para esperar lo mismo. La corrección es sacar la llamada a la pasarela fuera de la transacción —confirmar primero y cobrar después, en el AFTER_COMMIT de 07-03— y verificar que el connection-timeout es de segundos, no de treinta.

Solución 2.

Orden de las columnas: estado primero porque es el predicado de igualdad; inicio después porque es de rango —una columna de rango en el índice «consume» el resto para futuras igualdades, así que va detrás de todas las igualdades—; y estacion_origen_id al final para que el índice cubra la consulta: PostgreSQL puede agrupar leyendo solo el índice (Index Only Scan) sin visitar la tabla.

¿Parcial? Sí, y es la mejor decisión del ejercicio:

Los alquileres EN_CURSO son unos cientos entre 3,2 millones. El índice parcial ocupa kilobytes en lugar de ~150 MB, se mantiene casi gratis en cada escritura y, como todas las filas indexadas cumplen ya el filtro de estado, el planificador solo tiene que recorrer el rango de la última hora.

Efecto estimado: de Seq Scan sobre 3,2 millones de filas (~1,8 s) a recorrer unos cientos de entradas contiguas del índice: por debajo de 5 ms, dos o tres órdenes de magnitud. Verificación obligatoria: repetir EXPLAIN (ANALYZE, BUFFERS) y comprobar que aparece Index Scan/Index Only Scan, que Rows Removed by Filter desaparece y que Buffers: read cae a unas decenas. Y CONCURRENTLY porque la tabla está en producción: sin él, el CREATE INDEX bloquea las escrituras durante toda la construcción (04-08).

Solución 3.

Concurrencia necesaria (Little): L = λ × W = 400 × 0,180 = 72 peticiones simultáneas dentro del sistema.

Pool de conexiones: la fórmula da 8 × 2 + 1 = 17, redondeamos a 20. ¿Aguanta? Cada petición ocupa una conexión 120 ms; una conexión sirve 1 / 0,120 = 8,3 peticiones por segundo; 20 conexiones dan 20 × 8,3 = 166 pet/s. No llega a 400: aquí se rompe primero.

Qué hacer, en orden. Primero, reducir el tiempo de base de datos por petición, que es la palanca correcta: dos consultas de 60 ms para iniciar un alquiler es muchísimo y con los índices adecuados bajan a 5 ms, de modo que con W_bd = 10 ms una conexión sirve 100 pet/s y 20 conexiones dan 2.000 pet/s, cinco veces el objetivo. Solo si tras optimizar sigue faltando capacidad, escalar horizontalmente (08-04): tres instancias con 20 conexiones cada una son 60 conexiones contra la base de datos, cerca del límite razonable para 8 núcleos, y el paso siguiente serían réplicas de lectura. Lo que sería un error es subir el pool a 80: 80 conexiones activas sobre 8 núcleos multiplican los cambios de contexto y la competencia por bloqueos, el rendimiento agregado baja y el p95 sube.

Hilos de Tomcat: con L = 72, los 200 por defecto sobran holgadamente; threads.max: 200 y accept-count: 100 son correctos. Con hilos virtuales activados, el límite efectivo pasa a ser el pool de conexiones, lo que refuerza la conclusión: el objetivo se cumple optimizando las consultas, no ampliando pools.

Latencia resultante: con las consultas a 10 ms, W ≈ 70 ms y L = 400 × 0,07 = 28. Muy por debajo del SLO de 250 ms en p95, con margen para la variabilidad.

CicloUrbana ya no se ajusta por intuición. Tienes un método que no se salta pasos —definir el objetivo, medir la línea base, localizar el cuello, corregir una cosa, volver a medir— y sabes por qué la media miente y por qué el SLO se escribe en p95 y p99, con los 20 ciudadanos de cada 1.000 que la media escondía. Sabes montar una prueba de carga con k6 que reproduce la hora punta de Ribalta, con rampa, meseta y thresholds que ponen en rojo la canalización de 08-05, y leer su salida en el orden correcto: umbrales, errores, percentiles frente a media, operación concreta y saturación. La ley de Little te dice cuánta concurrencia hay realmente dentro del sistema y, con ella, si un pool está bien dimensionado; la de Amdahl te dice que optimizar la serialización un 900 % mejora el total un 5 %, y por eso el recorrido está ordenado.

Ese recorrido lo has hecho entero. La base de datos primero: detectar el N+1 de 04-04 con generate_statistics y con un contador de consultas por petición que avisa solo, y corregirlo con @EntityGraph, JOIN FETCH o —mejor— una proyección; leer un EXPLAIN ANALYZE distinguiendo Seq Scan de Index Scan y sabiendo qué significan Rows Removed by Filter y Buffers; diseñar índices compuestos con las igualdades delante y el orden detrás, índices parciales que ocupan kilobytes, y borrar los que nadie usa. Después la paginación por keyset frente al OFFSET grande, las proyecciones frente a las entidades, readOnly y los lotes de Hibernate. Luego HikariCP, con la fórmula y la explicación de por qué un pool grande empeora las cosas, y pending como la señal que distingue «falta pool» de «sobran consultas». Y por último la JVM —MaxRAMPercentage, G1 frente a ZGC, leer -Xlog:gc y reconocer la memoria que sube y no baja—, los hilos de Tomcat y su relación con el pool, los hilos virtuales de 07-03 como alternativa, la compresión y el perfilado con async-profiler, JFR y los volcados de 07-01.

El caso práctico resume la lección entera: un endpoint con p95 de 2,4 s, 43 consultas por petición y un Seq Scan, que tras quitar trabajo —una proyección y un índice— responde en 91 ms y multiplica por cinco el rendimiento, sin una máquina más y sin una caché. Ese orden importa: primero se elimina el trabajo innecesario. Pero cuando el trabajo ya es mínimo y aun así se repite mil veces por minuto para devolver siempre lo mismo —el catálogo de estaciones de Ribalta, que cambia una vez al mes y se consulta cien veces por segundo—, queda una palanca distinta: no ejecutarlo. La siguiente lección, Caché con Spring Cache, la desarrolla entera: qué datos merecen caché y cuáles no, @Cacheable y sus trampas, Caffeine y Redis, y la parte de verdad difícil, que es invalidar.