La lliçó anterior va tancar amb una promesa: CicloUrbana és en producció i hi arriba sola, i a partir d'ara la veurem funcionar i farem que vagi ràpid. Aquest és el primer pas, i convé començar desfent un malentès: ajustar el rendiment no consisteix a aplicar trucs. No és afegir una memòria cau, pujar el pool de connexions a 100 ni canviar el recol·lector d'escombraries perquè en un article deien que era més ràpid. Tot això són palanques, i sense un mètode al darrere són tres maneres diferents de moure un número a l'atzar.

El mètode és curt i no s'estalvia cap pas: mesurar, trobar el coll d'ampolla, corregir una sola cosa, tornar a mesurar. Aquesta lliçó el recorre sencer sobre la xarxa de Ribalta. Veurem per què la mitjana de latència menteix i què cal mirar en el seu lloc, com establir una línia base amb una prova de càrrega que reprodueixi l'hora punta, dues lleis que diuen on val la pena esforçar-se, i després el recorregut prioritzat pels llocs on de debò se'n va el temps: la base de dades primer —l'N+1 i els índexs—, després el pool de connexions, la JVM, els fils i la xarxa. Acabarem amb un cas complet: un endpoint que triga 2,4 segons en p95 i acaba trigant 90 mil·lisegons.

1. El mètode: no optimitzar mai sense mesurar
2. Objectius: SLI, SLO i per què la mitjana menteix
3. La línia base: la prova de càrrega
4. Un script de k6 per a l'hora punta de Ribalta
5. Llegir els resultats de la prova
6. Dues lleis pràctiques: Little i Amdahl
7. On se'n va el temps en una aplicació Spring Boot
8. La base de dades (I): detectar l'N+1
9. La base de dades (II): índexs i EXPLAIN ANALYZE
10. La base de dades (III): paginació, projeccions i lots
11. HikariCP: dimensionar el pool amb criteri
12. La JVM: memòria, recol·lector i pauses
13. Fils: Tomcat, el pool i els fils virtuals
14. La xarxa: compressió i mida de la resposta
15. Perfilatge: async-profiler, JFR i bolcats
16. Cas pràctic: l'endpoint d'estacions
17. Errors Comuns i Consells
18. Exercicis

Hi ha una frase de Donald Knuth que tothom cita a mitges. La completa diu: «els programadors gasten una quantitat enorme de temps preocupant-se per la velocitat de parts no crítiques, i aquests intents tenen un impacte molt negatiu quan es consideren la depuració i el manteniment. Hauríem d'oblidar-nos de les petites eficiències, diguem el 97 % del temps: l'optimització prematura és l'arrel de tots els mals. Tot i així, no hauríem de deixar passar les nostres oportunitats en aquest 3 % crític.»

El que importa és el final: existeix un 3 % crític i cal trobar-lo. L'error no és optimitzar, és optimitzar a cegues. I la intuïció sobre on és aquest 3 % és notòriament dolenta: gairebé tots els desenvolupadors aposten pel seu propi codi Java, quan en una aplicació com CicloUrbana el temps es passa gairebé sempre esperant la base de dades o un servei remot.

El cicle de treball és aquest:

Tres regles governen aquest cicle. Un canvi cada vegada: si toques el pool, la memòria cau i l'índex alhora i millora, no saps quin ha servit ni quin està empitjorant una altra cosa —i a CicloUrbana aquesta disciplina és barata, perquè cada canvi és un desplegament automàtic (08-05)—. Parar quan es compleix l'objectiu: sense criteri d'aturada l'ajust no s'acaba mai i acaba afegint complexitat que ningú no necessita; «ràpid» no és un objectiu, «p95 per sota de 300 ms amb 200 usuaris concurrents» sí que ho és. I mesurar on importa: un System.currentTimeMillis() al voltant d'un mètode al teu portàtil, amb la base de dades buida i sense concurrència, no diu res sobre Ribalta a les vuit del matí.

Abans de mesurar cal decidir què es mesura i quin valor és acceptable:

L'elecció de l'estadístic no és un detall: és la decisió més important de tot el capítol. Suposem 1.000 peticions a l'endpoint d'inici de lloguer en una hora punta de Ribalta:

La mitjana és (900×40 + 80×300 + 20×3000) / 1000 = 120 ms. Un número excel·lent que es pot portar a una reunió sense envermellir. Ara els percentils: ordenades les 1.000 latències, la posició 950 (p95) cau al grup de 300 ms, i la posició 990 (p99) cau al grup de 3.000 ms.

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

Les mateixes dades expliquen dues històries oposades. I la que importa és la segona: 20 de cada 1.000 ciutadans esperen tres segons mirant la pantalla del mòbil davant d'una bicicleta. En una hora punta amb 12.000 lloguers, són 240 persones cada matí. La mitjana els ha amagat perquè fa la mitjana sobre una distribució amb cua llarga, que és exactament la forma que tenen totes les distribucions de latència reals.

Quatre regles pràctiques. La mitjana no és mai el SLO: serveix, com a molt, per detectar una regressió grollera. p95 descriu l'experiència típica dolenta i p99 o p99,9 la pitjor, i com més crític és el servei més a la dreta cal mirar. Els percentils no es promitgen: la mitjana dels p95 de tres instàncies no és el p95 del conjunt, una cosa amb conseqüències tècniques molt concretes que veurem a 09-03 amb els histogrames. I latència i disponibilitat es miren juntes, perquè un endpoint que retorna 500 en 5 ms té un p99 magnífic.

Sense línia base no hi ha millora, només sensació de millora. Una prova de càrrega sotmet l'aplicació a un trànsit controlat i reproduïble, per poder comparar l'abans i el després amb el mateix patró.

Triem k6: l'escenari viu al costat del codi, s'executa a la canalització de 08-05 i no necessita una màquina potent per generar 500 usuaris virtuals. Tres advertiments abans de l'script: no provis contra producció sense acordar-ho —es prova contra pre (07-02) i amb dades de volum realista, perquè una base amb 12 estacions i 30 lloguers no revela res—; el generador no pot ser el coll d'ampolla, així que si k6 corre al mateix portàtil que l'aplicació estàs mesurant el portàtil; i escalfa la JVM, perquè els primers segons són codi interpretat i pool fred, i es descarten.

L'escenari reprodueix el que passa entre les 7:45 i les 9:15 a Ribalta: molta gent consulta estacions properes, una part inicia un lloguer i, uns minuts després, el finalitza.

Què fa cada peça i per què. stages defineix la forma de la càrrega, i la rampa inicial no és cortesia: sense ella es mesura la JVM interpretant bytecode i HikariCP obrint connexions, no l'estat estacionari —l'altiplà és l'única part els números de la qual valen—. thresholds converteix el SLO en una condició de fallada: si no es compleix, k6 surt amb un codi diferent de zero i la canalització de 08-05 es posa en vermell, de manera que el rendiment deixa de ser una opinió i passa a ser una prova. setup() s'executa una vegada i comparteix el token amb tots els usuaris virtuals, per no mesurar el cost del login a cada iteració. sleep() és imprescindible: sense pauses no se simulen 200 ciutadans, se simula un atac; el temps de reflexió és el que fa que la concurrència de l'escenari s'assembli a la real. I les mètriques pròpies (Trend, Rate) separen el SLO de negoci —iniciar un lloguer— de l'agregat de totes les peticions.

S'executa així:

Com s'interpreta, en ordre. Ha fallat cap llindar? Sí: el p95 global és 1,19 s davant dels 300 ms del SLO, així que la prova ha fet la seva feina. Hi ha errors? Un 0,71 %, per sota del llindar de l'1 %, però no és soroll i cal mirar de quin tipus són: un 500 és una fallada, mentre que un 409 pot ser l'índex únic parcial de 04-08 rebutjant un segon lloguer del mateix usuari, cosa que és correcta. Mitjana contra percentils? avg=214ms davant de p(95)=1.19s i max=4.8s: la cua llarga de l'apartat 2, exactament. Quina operació concreta? lloguer_inici_ms té un p95 de 2,41 s amb una mediana de 210 ms, per tant el problema no està repartit: és en un punt i només sota càrrega —una operació amb mediana bona i p95 deu vegades pitjor gairebé sempre espera per un recurs compartit: una connexió del pool, un bloqueig de fila o una pausa de GC—. Escala? 112 peticions per segon amb 200 usuaris virtuals; si en doblar els usuaris el rendiment no puja i la latència sí, s'ha assolit la saturació i hi ha un recurs limitat al darrere.

Aquesta és la línia base. Es desa al repositori amb la data i la versió desplegada, perquè l'única manera honesta d'afirmar «això va més ràpid» és comparar-hi.

La llei de Little relaciona tres magnituds en qualsevol sistema estable:

Amb els números de la prova: λ = 112 pet/s, W = 0,214 s de mitjana, per tant L = 24 peticions dins del sistema alhora. Aquest número és or:

• Si hi ha 24 peticions concurrents i el pool d'HikariCP té 10 connexions, hi ha peticions esperant connexió. Aquí tens el candidat.
• Si Tomcat té 200 fils i només se'n fan servir 24, pujar els fils no arregla res. És l'error més freqüent de l'ajust per intuïció.
• Al revés: si l'objectiu és 300 peticions per segon amb 200 ms de latència, caldrà suportar L = 60 peticions simultànies. La llei et diu el requisit abans de provar.

La llei d'Amdahl diu quant pot millorar el conjunt en accelerar-ne una part:

on P és la fracció del temps que ocupa la part optimitzada i S quant s'accelera. Dos casos de CicloUrbana:

La lectura és demolidora: fer deu vegades més ràpida la serialització millora el conjunt un 5 %. Mitja setmana de feina per a un guany que no es veu. Per això el primer pas sempre és esbrinar el repartiment del temps, i per això la taula de l'apartat següent està ordenada.

Repartiment típic en una aplicació de gestió com CicloUrbana, amb l'ordre en què convé buscar:

La conclusió pràctica: comença sempre per la base de dades i baixa per la llista. I no passis al nivell següent fins que no hagis esgotat l'anterior, perquè l'ordre reflecteix la llei d'Amdahl aplicada al cas mitjà.

Recuperem el problema de 04-04 amb la formulació operativa: el nombre de consultes d'un endpoint ha de ser constant, no proporcional al nombre de resultats. Primer, veure-ho. A dev n'hi ha prou d'obrir el SQL:

El resum de generate_statistics és la dada clau:

201 sentències per llistar 200 estacions. No cal més diagnòstic.

Veure el SQL a mà no escala: tan bon punt l'endpoint és complex, ningú no compta línies. La solució és un comptador de consultes per petició, amb datasource-proxy:

S'embolcalla el DataSource en un BeanPostProcessor anotat amb @Profile({"dev","test"}) —mai en producció, perquè intercepta cada consulta— que retorna ProxyDataSourceBuilder.create(ds).name("ciclourbana").countQuery().logSlowQueryBySlf4j(200, MILLISECONDS).build(): countQuery() acumula el recompte per fil i logSlowQueryBySlf4j avisa de les consultes que passen de 200 ms. A sobre, un filtre escriu al final de cada petició quantes consultes s'han executat —i com que el FiltreRastreig de 03-06 ja ha posat el rastreId al MDC, la línia és directament correlacionable amb la resta del log:

Amb això, un endpoint que es degrada avisa sol tan bon punt algú introdueix un getBicicletes() dins d'un bucle. I la tècnica arriba fins a les proves: en un @DataJpaTest (06-04) es pot afirmar assertThat(comptador.getTotal()).isEqualTo(1), i així «no hi ha N+1» es converteix en una prova de regressió de debò.

La correcció ja la coneixem de 04-04 i 04-06: @EntityGraph(attributePaths = "bicicletes") o JOIN FETCH quan calen les entitats, @BatchSize quan la col·lecció es pagina, i —sovint la millor— una projecció que faci comptar la base de dades i no porti entitats en absolut.

Un índex és una estructura auxiliar que evita llegir la taula sencera. La pregunta no és «hi poso un índex?» sinó «quines columnes filtren i ordenen les meves consultes reals?». I la resposta la dóna PostgreSQL, no la intuïció.

La consulta de l'històric del ciutadà:

Abans de tocar res, amb 3,2 milions de files:

Com es llegeix, de dins cap enfora:

Ja existia idx_lloguers_usuari de 04-08, però el planificador el descarta: amb 27.000 lloguers d'aquest usuari, saltar de l'índex a la taula 27.000 vegades li surt més car que escombrar-la. La solució és un índex compost que cobreixi el filtre i l'ordre:

De 812 ms a 0,08 ms: gairebé deu mil vegades. No hi ha cap optimització de codi Java capaç d'acostar-s'hi, i aquest és l'argument de tota la lliçó.

L'ordre de les columnes de l'índex compost no és arbitrari. La regla, en aquest ordre: primer les columnes d'igualtat (usuari_id, estat), després les de rang o ordre (inici DESC). Un índex (usuari_id, estat, inici) serveix per consultar per usuari_id, per usuari_id + estat i pels tres; no serveix per consultar només per estat. És el principi del prefix esquerre, i explica per què un índex ben pensat sol fer-ne innecessaris dos o tres.

Índexs parcials. Quan només interessa un subconjunt:

Ocupa kilobytes en lloc de centenars de megabytes i és el mateix mecanisme de l'uk_lloguers_usuari_en_curs de 04-08.

El cost d'indexar de més. Un índex no és gratis: ocupa espai, cada INSERT, UPDATE i DELETE l'ha d'actualitzar, i empitjora la feina del planificador. Una taula amb dotze índexs pot trigar el triple a escriure. Per saber quins sobren:

idx_scan = 0 després de setmanes en producció significa que aquest índex només costa. I per trobar les consultes cares, l'extensió pg_stat_statements ordenada per total_exec_time respon a la pregunta «quina consulta consumeix el 40 % del temps de base de dades».

L'OFFSET gran. Pageable genera LIMIT 20 OFFSET 200000, i PostgreSQL ha de produir i descartar 200.000 files abans de retornar-ne 20. La pàgina 1 vola; la pàgina 10.000 triga segons. Per a llistats profunds —l'històric complet de lloguers, una exportació— s'utilitza paginació per keyset:

El client envia l'última fila vista en lloc d'un número de pàgina. La consulta fa servir l'índex per posicionar-se en lloc de comptar, i el cost és constant a qualsevol profunditat. Els seus límits: no permet saltar a la pàgina 500 ni mostrar el total —i aquest count(*) de cada Page és, moltes vegades, més car que la consulta de dades: per això existeix Slice, que l'evita.

Projeccions davant d'entitats (04-06). Carregar l'entitat completa porta totes les columnes, crea objectes gestionats al context de persistència i obliga Hibernate a fer dirty checking sobre cadascun en confirmar:

La regla de CicloUrbana: els endpoints de només lectura retornen projeccions. És simultàniament més ràpid i més segur.

readOnly i lots. @Transactional(readOnly = true) (04-07) fa que Hibernate faci servir FlushMode.MANUAL i no desi l'estat original per comparar: menys memòria i menys CPU a cada lectura. I per a les escriptures massives de l'importador nocturn:

Inserir 10.000 files passa de 10.000 viatges de xarxa a 200. Requisit: el generador d'identificadors no pot ser IDENTITY, perquè obliga a executar cada INSERT per separat per conèixer la clau; per això CicloUrbana fa servir seqüències amb allocationSize = 50 des de 04-03.

La intuïció diu «més connexions, més rendiment». És falsa, i el motiu és que una connexió ocupada és un nucli de CPU i un disc de la base de dades treballant. Quan hi ha més connexions actives que capacitat real, el servidor de base de dades dedica temps a canviar de context i a competir per bloqueigs: el rendiment baixa i la latència puja.

La fórmula que documenta el mateix HikariCP:

La instància de PostgreSQL de CicloUrbana té 4 nuclis i emmagatzematge SSD en xarxa (1 «disc» efectiu): 4 × 2 + 1 = 9, arrodonit a 10. Sí, deu connexions serveixen 112 peticions per segon: per la llei de Little, si una consulta dura 5 ms, cada connexió pot atendre 200 consultes per segon.

Quatre detalls amb conseqüències. minimum-idle igual que maximum-pool-size: un pool elàstic estalvia uns recursos irrellevants i afegeix la latència d'una handshake TCP més autenticació justament quan arriba el pic. connection-timeout: 3000: si no hi ha connexió en 3 segons es llança una excepció, mentre que un valor de 30 s converteix una degradació en una cua que acaba consumint els 200 fils de Tomcat —així és com un problema de base de dades enderroca l'aplicació sencera—. leak-detection-threshold avisa d'una connexió retinguda més de 20 s, símptoma clàssic d'una crida HTTP dins d'una transacció. I max-lifetime ha de ser menor que el temps de tancament del costat servidor, o el pool lliurarà connexions mortes.

Detectar l'espera és el que decideix si el pool està mal dimensionat. La mètrica hikaricp.connections.pending (09-03) mesura quants fils esperen i hikaricp.connections.acquire quant triguen. Si pending és persistentment més gran que zero hi ha dues causes possibles i només una s'arregla pujant el pool: si les consultes són lentes o les transaccions llarguíssimes, arregla això i no el pool; si la base de dades va sobrada i la concurrència és real, puja el pool amb moderació i torna a mesurar.

Memòria en contenidor (07-04). La JVM moderna detecta els límits del cgroup, però per defecte reserva només el 25 % de la memòria disponible per al heap. En un contenidor d'1 GB això són 256 MB, i la resta es malbarata:

El 75 % —no el 100 %— deixa lloc per al que no és heap: metaespai, piles de fils, memòries intermèdies directes i la mateixa JVM. Si el heap ocupa tot el límit del contenidor, el procés mor amb OOMKilled (codi 137) sense deixar ni una excepció, i el restartPolicy de Kubernetes el reinicia en bucle. +ExitOnOutOfMemoryError és preferible a arrossegar-se: una instància amb la memòria esgotada respon malament i continua rebent trànsit; morta, la sonda de 07-01 la treu del balancejador.

Triar recol·lector:

El criteri real: no canviïs de recol·lector fins que no hagis comprovat, als logs de GC, que les pauses expliquen el teu p99. Amb 2 GB de heap i G1, les pauses de CicloUrbana són de 15-40 ms; el p95 d'1,19 s no ve d'aquí.

Llegir els logs de GC:

Què cal mirar. La notació 1204M->318M(2048M) és abans → després (total): ha recuperat 886 MB, per tant és sa. En canvi 1902M->1841M ha recuperat 61 MB d'1,9 GB, és a dir, la memòria ja no baixa —fuita o heap insuficient—, que és exactament el símptoma que anticipava el tancament de 08-05. La Pause Full d'1,8 s atura tots els fils i una de sola n'hi ha prou per explicar un p99 desastrós; si es repeteixen, s'acosta un OutOfMemoryError. I la freqüència importa tant com la durada: pauses joves curtes cada pocs segons són el normal, però cada 200 ms significa que es genera brossa a mans plenes, gairebé sempre per carregar entitats que no calen —l'apartat 10 un altre cop—.

La relació entre tots dos pools és la font d'un malentès car. Amb 200 fils de Tomcat i 10 connexions d'HikariCP, fins a 190 fils poden estar bloquejats esperant una connexió. Això no és una fallada de disseny: és un embut deliberat que protegeix la base de dades. El que sí que és una fallada és no acotar l'espera —d'aquí el connection-timeout: 3000 de l'apartat 11—.

I pujar threads.max a 800 gairebé mai no ajuda: si el coll és a les 10 connexions, els 600 fils nous només afegeixen 600 piles d'1 MB i més canvis de context. La llei de Little diu quants fils calen de debò: fils ≈ λ × W; amb 112 pet/s i 214 ms, uns 24.

Fils virtuals (07-03), a Java 21 i Spring Boot 3.2+:

Cada petició s'atén en un fil virtual, que en bloquejar-se en E/S allibera el fil de plataforma en lloc d'ocupar-lo. Per a una aplicació com CicloUrbana —bloquejant i amb molta espera de base de dades— és la manera més barata de sostenir alta concurrència sense pila reactiva. Amb dos advertiments que ja hem vist: synchronized al voltant d'una operació bloquejant fixa el fil virtual i anul·la l'avantatge, i els ThreadLocal —el MDC del FiltreRastreig, el SecurityContext— continuen funcionant, però ja no hi ha un pool acotat que limiti la concurrència: el límit passa a ser el pool de connexions, així que el seu connection-timeout es torna encara més important.

El temps que el ciutadà percep inclou la transferència. Un llistat de 200 estacions en JSON són uns 180 KB; sobre una xarxa mòbil de Ribalta, mig segon per ell sol.

Amb JSON, gzip redueix entre un 70 % i un 90 % perquè el format repeteix les claus a cada element: 180 KB passen a uns 20 KB. El cost és CPU del servidor; si hi ha un proxy o un ALB al davant (08-03), sovint és millor que comprimeixi ell.

Però la millor compressió és no enviar la dada. Aquí és on els DTOs de 03-05 deixen de ser una qüestió de disseny i es converteixen en rendiment: EstacioResponse publica sis camps en lloc d'abocar l'entitat amb les seves auditories, la seva versio i la seva col·lecció de bicicletes. Menys bytes serialitzats, menys CPU, menys xarxa i menys memòria. Tres regles: pagina sempre els llistats (mai un findAll() sense Pageable), no imbriquis col·leccions completes a la resposta —enllaça a un subrecurs—, i fes servir ETag (03-03) perquè el client que ja té la dada rebi un 304 Not Modified de dos-cents bytes.

Quan la base de dades ja està neta i el temps continua anant-se'n a algun lloc, toca perfilar.

Com es llegeix un gràfic de flama. L'eix horitzontal no és temps: és la proporció de mostres. Cada barra és un mètode i a sobre hi ha els mètodes als quals crida. Es llegeix de baix a dalt buscant altiplans amples: una barra ampla significa que aquest mètode era a la pila en moltes mostres. Si l'altiplà és al capdamunt, aquest mètode consumeix CPU per ell mateix; si és ample però amb torres a sobre, el cost és en el que crida. A CicloUrbana, un perfilatge típic mostra un altiplà ample sota PgConnection.execSQLQuery —esperant la base de dades, que és l'esperat— i, si alguna cosa va malament al codi, una torre inesperada sota ObjectMapper.writeValue o sota un equals d'entitats.

I l'ús més rendible de /actuator/threaddump: amb l'aplicació lenta, es descarrega i es compten els fils per estat. Cinquanta fils http-nio-8080-exec-* en WAITING sobre HikariPool.getConnection és un diagnòstic tancat, sense necessitat de perfilar res.

Símptoma. GET /api/v1/estacions?page=0&size=20 té un p95 de 2,4 s a la prova de càrrega. La mediana és 210 ms.

Pas 1 — mesurar. El FiltreComptadorConsultes de l'apartat 8 escriu al log de pre:

43 consultes per a 20 estacions: 1 + 20 + 20 + 2. El patró és inequívoc.

Pas 2 — localitzar. El codi:

Dos N+1 encadenats. I comptarDisponibles executa select count(*) from bicicletes where estacio_id = ? and estat = 'DISPONIBLE', l'EXPLAIN ANALYZE de la qual revela un Seq Scan: idx_bicicletes_estat existeix, però per ell sol no filtra bé.

Pas 3 — corregir. Dos canvis, un per causa. Una projecció que fa comptar la base de dades en una sola consulta:

I l'índex compost que sosté aquesta subconsulta:

Igualtat primer, i amb les dues columnes del filtre l'índex cobreix la consulta: PostgreSQL compta sense tocar la taula.

Pas 4 — tornar a mesurar. Mateixa prova de k6, mateixa màquina, mateixes dades:

Quatre observacions valen més que els números. No s'hi ha afegit ni una memòria cau ni una màquina: s'ha tret feina innecessària. pending va baixar a zero sol, cosa que demostra que el pool no estava mal dimensionat sinó retingut per consultes de més —pujar-lo a 50 hauria amagat el problema i castigat la base de dades—. El p95 va millorar més que la mediana (26× davant de 7,5×), que és el típic quan la causa era espera per un recurs compartit. I el SLO de l'apartat 2 —p95 < 300 ms— es compleix, així que es para.

Aquest era el cas fàcil: hi havia feina malbaratada. Quan ja no n'hi ha i la consulta és mínima i està indexada, però es repeteix mil vegades per minut amb el mateix resultat, la palanca següent és diferent: no executar-la. Això és la memòria cau, i és la lliçó següent.

Optimitzar sense línia base i fer servir la mitjana com a objectiu. Sense un número anterior, «va més ràpid» és una impressió: desa el resultat de k6 amb la data i la versió al repositori. I la mitjana amaga exactament els usuaris pitjor tractats, així que el SLO s'escriu en p95 i p99.

Canviar diverses coses alhora. Si millores l'índex, puges el pool i actives la compressió al mateix desplegament, no sabràs quin ha valgut ni podràs revertir el que sobra.

Pujar el pool de connexions com a primera mesura. Gairebé sempre empitjora: trasllada la congestió de la teva aplicació a la base de dades, on és més difícil de veure i afecta tothom.

Mesurar al portàtil amb dades de joguina. Un Seq Scan sobre 40 files és instantani. Els problemes de rendiment són problemes de volum i de concurrència, i es reprodueixen a pre amb dades realistes.

Deixar org.hibernate.SQL: DEBUG o datasource-proxy en producció. Tots dos afegeixen cost per consulta i omplen el disc: van sota @Profile({"dev","test"}), i si cal veure SQL en producció es puja el nivell en calent amb /actuator/loggers (07-01) i es baixa després.

Confondre un Full GC amb «cal pujar la memòria». De vegades sí; moltes vegades és que es carreguen entitats que no calen. Mira primer l'apartat 10.

Consell: posa un límit de consultes per petició a les proves, amb un assertThat(comptador.getTotal()).isLessThanOrEqualTo(3) en un @DataJpaTest: és l'única manera que un N+1 no torni d'aquí a tres mesos. Executa a més la prova de càrrega a la canalització nocturna, perquè amb thresholds una regressió es detecta el dia que s'introdueix i no el dia que truca l'ajuntament. I EXPLAIN ANALYZE abans de crear un índex, amb una revisió de pg_stat_user_indexes cada trimestre per esborrar els que ningú no fa servir.

Després d'un desplegament, l'operació de CicloUrbana observa: p50 de POST /api/v1/lloguers = 45 ms (sense canvis), p99 = 4,2 s (abans 300 ms), CPU de l'aplicació al 20 %, CPU de la base de dades al 25 %, hikaricp.connections.pending amb pics de 60, cap Full GC, i el log del comptador de consultes diu «3 consultes en 4.100 ms». Formula la hipòtesi més probable, digues què comprovaries per confirmar-la i què no faries.

El quadre de comandament de l'ajuntament executa aquesta consulta cada minut i triga 1,8 s:

EXPLAIN ANALYZE mostra Seq Scan on lloguers amb Rows Removed by Filter: 3198412. Proposa l'índex, justifica l'ordre de les columnes, decideix si ha de ser parcial i estima l'efecte.

CicloUrbana ha de suportar 400 peticions per segon amb p95 < 250 ms. La latència mitjana mesurada és 180 ms, dels quals 120 ms són base de dades (dues consultes de 60 ms). El servidor de PostgreSQL té 8 nuclis i SSD. Calcula la concurrència necessària, dimensiona el pool d'HikariCP i els fils de Tomcat, i digues si el sistema pot complir l'objectiu o on es trencarà primer.

Solució 1.

Hipòtesi: espera per connexió del pool, no lentitud de l'aplicació. Els senyals encaixen un a un: la mediana intacta indica que el camí ràpid no ha canviat; el p99 disparat amb CPU baixa a banda i banda descarta saturació de càlcul; pending amb pics de 60 diu literalment que 60 fils esperen connexió; «3 consultes en 4.100 ms» és la signatura exacta —poques consultes, molt de temps—, perquè el temps no se'n va executant SQL sinó esperant per poder-lo executar; i l'absència de Full GC descarta pauses de memòria.

Causa més probable: alguna cosa reté connexions més temps del degut. Els dos sospitosos habituals: una crida HTTP dins d'una transacció —molt probable aquí, perquè el desplegament va tocar el cobrament i la passarel·la de 07-06 pot trigar segons— o una transacció allargada per feina que no necessita la base de dades.

Com confirmar-ho: amb /actuator/threaddump durant un pic, buscant fils http-nio-* en WAITING sobre HikariPool.getConnection i —sobretot— fils que ja tenen connexió i estan bloquejats en un sòcol de la passarel·la; activant leak-detection-threshold: 20000, la traça de pila del qual assenyala el mètode culpable; mirant les mètriques de Resilience4j (07-06), perquè si la latència de la passarel·la va pujar alhora el diagnòstic està tancat; i observant hikaricp.connections.usage, que mesura quant es reté cada connexió.

Què NO faria: pujar maximum-pool-size. Amb la CPU de la base de dades al 25 % el problema no és manca de capacitat, i més connexions retingudes per crides remotes només allarguen l'agonia. Tampoc pujar els fils de Tomcat: crearia més fils per esperar el mateix. La correcció és treure la crida a la passarel·la fora de la transacció —confirmar primer i cobrar després, a l'AFTER_COMMIT de 07-03— i verificar que el connection-timeout és de segons, no de trenta.

Solució 2.

Ordre de les columnes: estat primer perquè és el predicat d'igualtat; inici després perquè és de rang —una columna de rang a l'índex «consumeix» la resta per a futures igualtats, així que va darrere de totes les igualtats—; i estacio_origen_id al final perquè l'índex cobreixi la consulta: PostgreSQL pot agrupar llegint només l'índex (Index Only Scan) sense visitar la taula.

Parcial? Sí, i és la millor decisió de l'exercici:

Els lloguers EN_CURS són uns centenars entre 3,2 milions. L'índex parcial ocupa kilobytes en lloc de ~150 MB, es manté gairebé de franc a cada escriptura i, com que totes les files indexades ja compleixen el filtre d'estat, el planificador només ha de recórrer el rang de l'última hora.

Efecte estimat: de Seq Scan sobre 3,2 milions de files (~1,8 s) a recórrer uns centenars d'entrades contigües de l'índex: per sota de 5 ms, dos o tres ordres de magnitud. Verificació obligatòria: repetir EXPLAIN (ANALYZE, BUFFERS) i comprovar que apareix Index Scan/Index Only Scan, que Rows Removed by Filter desapareix i que Buffers: read cau a unes desenes. I CONCURRENTLY perquè la taula és en producció: sense això, el CREATE INDEX bloqueja les escriptures durant tota la construcció (04-08).

Solució 3.

Concurrència necessària (Little): L = λ × W = 400 × 0,180 = 72 peticions simultànies dins del sistema.

Pool de connexions: la fórmula dóna 8 × 2 + 1 = 17, arrodonim a 20. Aguanta? Cada petició ocupa una connexió 120 ms; una connexió serveix 1 / 0,120 = 8,3 peticions per segon; 20 connexions donen 20 × 8,3 = 166 pet/s. No arriba a 400: aquí es trenca primer.

Què fer, en ordre. Primer, reduir el temps de base de dades per petició, que és la palanca correcta: dues consultes de 60 ms per iniciar un lloguer és moltíssim i amb els índexs adequats baixen a 5 ms, de manera que amb W_bd = 10 ms una connexió serveix 100 pet/s i 20 connexions donen 2.000 pet/s, cinc vegades l'objectiu. Només si després d'optimitzar continua faltant capacitat, escalar horitzontalment (08-04): tres instàncies amb 20 connexions cadascuna són 60 connexions contra la base de dades, a prop del límit raonable per a 8 nuclis, i el pas següent serien rèpliques de lectura. El que seria un error és pujar el pool a 80: 80 connexions actives sobre 8 nuclis multipliquen els canvis de context i la competència per bloqueigs, el rendiment agregat baixa i el p95 puja.

Fils de Tomcat: amb L = 72, els 200 per defecte sobren de llarg; threads.max: 200 i accept-count: 100 són correctes. Amb fils virtuals activats, el límit efectiu passa a ser el pool de connexions, cosa que reforça la conclusió: l'objectiu es compleix optimitzant les consultes, no ampliant pools.

Latència resultant: amb les consultes a 10 ms, W ≈ 70 ms i L = 400 × 0,07 = 28. Molt per sota del SLO de 250 ms en p95, amb marge per a la variabilitat.

CicloUrbana ja no s'ajusta per intuïció. Tens un mètode que no s'estalvia passos —definir l'objectiu, mesurar la línia base, localitzar el coll, corregir una cosa, tornar a mesurar— i saps per què la mitjana menteix i per què el SLO s'escriu en p95 i p99, amb els 20 ciutadans de cada 1.000 que la mitjana amagava. Saps muntar una prova de càrrega amb k6 que reprodueix l'hora punta de Ribalta, amb rampa, altiplà i thresholds que posen en vermell la canalització de 08-05, i llegir-ne la sortida en l'ordre correcte: llindars, errors, percentils davant de mitjana, operació concreta i saturació. La llei de Little et diu quanta concurrència hi ha realment dins del sistema i, amb ella, si un pool està ben dimensionat; la d'Amdahl et diu que optimitzar la serialització un 900 % millora el total un 5 %, i per això el recorregut està ordenat.

Aquest recorregut l'has fet sencer. La base de dades primer: detectar l'N+1 de 04-04 amb generate_statistics i amb un comptador de consultes per petició que avisa sol, i corregir-lo amb @EntityGraph, JOIN FETCH o —millor— una projecció; llegir un EXPLAIN ANALYZE distingint Seq Scan d'Index Scan i sabent què signifiquen Rows Removed by Filter i Buffers; dissenyar índexs compostos amb les igualtats al davant i l'ordre al darrere, índexs parcials que ocupen kilobytes, i esborrar els que ningú no fa servir. Després la paginació per keyset davant de l'OFFSET gran, les projeccions davant de les entitats, readOnly i els lots d'Hibernate. Després HikariCP, amb la fórmula i l'explicació de per què un pool gran empitjora les coses, i pending com el senyal que distingeix «falta pool» de «sobren consultes». I finalment la JVM —MaxRAMPercentage, G1 davant de ZGC, llegir -Xlog:gc i reconèixer la memòria que puja i no baixa—, els fils de Tomcat i la seva relació amb el pool, els fils virtuals de 07-03 com a alternativa, la compressió i el perfilatge amb async-profiler, JFR i els bolcats de 07-01.

El cas pràctic resumeix la lliçó sencera: un endpoint amb un p95 de 2,4 s, 43 consultes per petició i un Seq Scan, que després de treure feina —una projecció i un índex— respon en 91 ms i multiplica per cinc el rendiment, sense una màquina més i sense memòria cau. Aquest ordre importa: primer s'elimina la feina innecessària. Però quan la feina ja és mínima i tot i així es repeteix mil vegades per minut per retornar sempre el mateix —el catàleg d'estacions de Ribalta, que canvia una vegada al mes i es consulta cent vegades per segon—, queda una palanca diferent: no executar-la. La lliçó següent, Memòria cau amb Spring Cache, la desenvolupa sencera: quines dades mereixen memòria cau i quines no, @Cacheable i els seus paranys, Caffeine i Redis, i la part de debò difícil, que és invalidar.