La lliçó anterior va repartir Escena Viva entre set treballadors i va multiplicar per gairebé cinc la capacitat del servidor. Però va deixar un problema intacte i ho vam dir sense embuts: cluster no desbloqueja el bucle d'esdeveniments. Quan un treballador es posa a compondre el PDF amb el codi QR de les 500 entrades de l'estrena del Festival de Jazz de Primavera (evt-003, Auditorio Ribera), aquell procés deixa d'atendre tothom durant el temps que duri el càlcul.

En aquesta lliçó mesurem aquest blocatge amb l'instrumental del mòdul 2, entenem per què els fils són l'eina correcta per al treball de CPU (i cluster no ho és), i construïm a Escena Viva un PoolDeFils propi, perquè crear un fil per petició és pitjor que no fer servir fils.

1. El blocatge, mesurat amb monitorEventLoopDelay
2. Cluster davant de worker threads: la regla de decisió
3. node:worker_threads: el mecanisme bàsic
4. Clonatge estructurat: què viatja entre fils i què costa
5. Transferència davant de còpia: ArrayBuffer, SharedArrayBuffer i Atomics
6. El fil d'Escena Viva: src/treballadors/generar-entrades.js
7. PoolDeFils: per què un fil per petició és un error
8. Errors dins del fil i com es propaguen
9. Mesura abans i després
10. Quan NO fer servir fils

Al mòdul 3 vam deixar src/utils/qr-entrada.js amb { codificarQr, descodificarQr }: signa el contingut amb HMAC i el codifica en base64url. En generar les entrades d'una sessió sencera cal fer-ho una vegada per entrada, més la composició del PDF. És treball síncron i de CPU: no hi ha E/S per delegar, només càlcul.

El mesurarem abans d'opinar. Aquest script simula la generació de les 500 entrades de l'estrena mentre un temporitzador intenta bategar cada 20 ms:

Resultat a la màquina de referència: Generacio: 4180 ms, Batecs: 3 (esperats ~209), Retard maxim: 4176.44 ms.

Tres batecs on n'hi hauria d'haver 209. Durant 4,18 segons el procés no va executar absolutament res més: ni va respondre peticions, ni va atendre la connexió a PostgreSQL, ni va processar el keep-alive. Amb SCHED_RR, el primari li va continuar enviant connexions —no sap que està ocupat— i aquelles connexions es van quedar a la cua del sistema. Quan el treballador va tornar, tenia un embús esperant-lo i el percentil 99 de tota l'aplicació es va disparar. Amb 7 treballadors el mal és 1/7 del trànsit; però si tres organitzadors generen entrades alhora (una cosa normal la nit de l'estrena), tres de set treballadors estan congelats.

La regla de decisió, que convé memoritzar: cluster per escalar l'E/S, fils per treure la CPU del camí. No són alternatives: a Escena Viva farem servir totes dues. Set treballadors de cluster, i dins de cadascun un pool petit de fils per a la feina pesada. I compte amb l'aritmètica: 7 treballadors × 4 fils = 28 fils de CPU en una màquina de 8 nuclis és sobrevenda. Hi tornarem a l'apartat 7.

El mòdul exposa l'essencial en molt poques peces:

Un exemple mínim, amb els esdeveniments que importen:

I el fitxer del fil, on workerData arriba ja clonat (és una còpia, no una referència):

Dos matisos importants. Primer, postMessage no acaba el fil; el fil viu fins que es queda sense feina pendent o algú crida terminate(), i pot continuar rebent tasques per parentPort.on('message', ...). Això és precisament el que permet reutilitzar-lo en un pool. Segon, cada fil carrega els seus propis mòduls: si generar-entrades.js fa require de Sequelize, aquell require s'executa una vegada per fil, amb el seu cost d'arrencada i de memòria.

Els missatges entre fils no comparteixen memòria per defecte: es copien amb l'algorisme de clonatge estructurat (el mateix de postMessage al navegador i de structuredClone). És més capaç que JSON.stringify, però té límits estrictes.

Conseqüència directa per a Escena Viva: no pots enviar una instància d'Entrada ni de Comanda i esperar que conservi els seus mètodes. El nostre domini (src/domini/) fa servir classes; en creuar la frontera del fil cal serialitzar a dades planes i reconstruir a l'altre costat, i per això ho dissenyarem així: el fil rep dades primitives i retorna dades primitives. El cost de copiar tampoc no és zero: clonar 500 objectes d'entrada és de l'ordre d'un mil·lisegon, però clonar un PDF de 8 MB com a Buffer és de l'ordre de desenes. Si el resultat és gran, transfereix-lo en comptes de copiar-lo.

postMessage accepta un segon argument amb la llista d'objectes transferibles: parentPort.postMessage({ dades: arrayBuffer }, [arrayBuffer]). Un ArrayBuffer transferit no es copia, canvia d'amo, i el fil emissor es queda amb una memòria intermèdia desconnectada (byteLength === 0). És la manera correcta de retornar un PDF de diversos megabytes, i la veurem aplicada a l'apartat 6.

SharedArrayBuffer va un pas més enllà: la mateixa memòria és visible des de diversos fils alhora, sense còpia ni transferència. És l'eina per a comptadors compartits, com el nombre d'entrades generades a l'estrena:

Advertiment seriós. Fins ara, en JavaScript d'un sol fil, les condicions de carrera de memòria no existien: entre dues línies de la teva funció ningú no podia modificar les teves variables. SharedArrayBuffer obre aquesta porta. comptadors[0] += 1 són tres operacions (llegir, sumar, escriure) i dos fils poden entrellaçar-les i perdre increments. Per això existeix Atomics (add, load, store, compareExchange, wait, notify). Fes-lo servir sempre per tocar memòria compartida, i fes servir memòria compartida només quan de debò calgui: per a dades estructurades, el clonatge és més lent però infinitament més segur.

El fil rep les dades planes d'un lot d'entrades, genera per a cadascuna el seu QR signat reutilitzant codificarQr del mòdul 3, compon el PDF i retorna el resultat transferint la memòria intermèdia.

Fixa't en la decisió de disseny: el fil no llança excepcions cap amunt, les converteix en respostes. Un throw sense capturar dispararia l'esdeveniment error i mataria el fil, obligant el pool a crear-ne un altre. Capturar a dins i respondre amb ok: false manté el fil reutilitzable.

Hem mesurat el cost d'arrencada d'un fil que fa require del nostre codi: entre 18 i 40 ms. Si la tasca dura 4 000 ms, aquest cost és soroll. Però per a lots petits —una entrada solta de Lucía per a ses-001-1— la tasca dura 12 ms i l'arrencada costa el triple que la feina. Encara pitjor: 50 peticions simultànies crearien 50 fils, és a dir 50 instàncies de V8 competint per 8 nuclis, amb centenars de megabytes de memòria i un col·lapse per canvi de context.

La solució és un pool: un nombre fix i petit de fils creats a l'arrencada, una cua de tasques, i reutilització.

Sobre la mida del pool: per a feina purament de CPU, més fils que nuclis no aporta res, només canvi de context. I com que cada treballador de cluster té el seu propi pool, el càlcul real és treballadorsCluster × midaDelPool ≤ nuclis. Amb 7 treballadors en 8 nuclis, el pool hauria de ser d'1 o 2 fils. Aquesta tensió —cluster i fils competint pels mateixos nuclis— és la raó per la qual moltes arquitectures acaben traient la feina pesada del servidor web del tot, cap a un procés a part amb una cua: la lliçó 10-03. En producció, a més, la biblioteca piscina fa tot això i més (cancel·lació amb AbortSignal, reciclatge de fils després de N tasques, límits de cua, mètriques); hem escrit el nostre per entendre què fa per dins.

El servei d'aplicació queda així de simple:

Encaixa sense fricció amb la refacció del mòdul 9: els controladors són factories amb dependències injectades, així que el pool s'injecta com una dependència més i a les proves se substitueix per un doble de Sinon.

Un matís sobre el temps límit: el nostre executar rebutja la promesa, però el fil continua calculant. Per a un bucle infinit real cal cridar terminate() i recrear el fil (exercici 2).

Escenari: estrena del Festival de Jazz, amb una càrrega base de 500 peticions per segon al catàleg i, cada 2 segons, un organitzador que sol·licita el PDF d'un lot de 500 entrades.

Llegeix l'última fila amb atenció: la generació triga una mica més (4 390 davant de 4 180 ms), perquè cal clonar la petició d'entrada, transferir el resultat i coordinar el pool. Els fils no acceleren la tasca pesada; el que fan és treure-la del camí de tots els altres. El p99 del catàleg cau de 6,8 segons a 74 mil·lisegons, i aquesta és l'única xifra que importa a qui està intentant comprar una entrada mentre es genera el lot.

Els fils tenen un cost real (memòria, arrencada, complexitat, serialització). No els facis servir si:

1. La tasca és d'E/S. Llegir un fitxer, consultar PostgreSQL, cridar l'API de divises: això ja és asíncron i no bloqueja res. Ficar una consulta SQL en un fil no l'accelera; només afegeix una còpia de dades i un salt entre fils. Aquest és el malentès més freqüent.
2. La tasca és trivial. Si la feina dura 2 ms, el clonatge i el traspàs costen més que fer-la al mateix lloc. Llindar orientatiu: per sota de ~10-20 ms de CPU, no compensa.
3. La tasca es pot trossejar. Al mòdul 2 vam veure com partir un bucle llarg amb setImmediate per retornar el control al bucle entre trossos. Si la feina es deixa tallar netament i no és enorme, trossejar és més simple que un pool.

Trossejar redueix el retard màxim del bucle a la durada d'un bloc (uns 200 ms en el nostre cas), cosa que ja és acceptable per a moltes aplicacions, i no costa ni un fil ni un megabyte. La contrapartida és que la tasca total triga més i continua consumint l'únic fil principal.

4. La tasca és realment llarga. Si generar i enviar per correu les 500 entrades de l'estrena triga minuts, ni el fil ni el trossejat són la resposta: la petició HTTP no hauria d'esperar gens. Cal treure la feina del procés i encuar-la, respondre 202 Accepted amb un identificador, i que el client consulti l'estat. Aquest és el tema de la lliçó següent.

• Crear un Worker per petició. L'error més car. Pool sempre, creat en arrencar el procés.
• Enviar instàncies de classes del domini. Arriben com a objectes plans sense mètodes: serialitza a dades i reconstrueix a l'altre costat.
• Ficar E/S en un fil. No millora res: l'E/S ja era asíncrona.
• Fer servir SharedArrayBuffer sense Atomics, o oblidar que un ArrayBuffer transferit queda buit a l'emissor.
• No posar temps límit a les tasques. Un fil penjat reté la seva plaça del pool per sempre i acaba aturant tota la generació.
• Consell: exposa pool.estat() al teu punt d'entrada de salut. Una cua que creix sense parar et diu que el pool està infradimensionat o que cal encuar fora del procés.
• Consell: mesura sempre amb monitorEventLoopDelay abans i després. Si el retard no baixa, els fils no eren el problema.

Escriu un script que arrenqui un servidor HTTP mínim amb una ruta /bloquejar que calculi 500 hashos SHA-256 amb 100 000 iteracions cadascun de manera síncrona, i una ruta /ping que respongui { ok: true }. Amb autocannon contra /ping, mesura el p99 en repòs i mentre s'executa /bloquejar. Registra el retard del bucle amb monitorEventLoopDelay.

Modifica PoolDeFils perquè, en exhaurir-se tempsLimitMs, a més de rebutjar la promesa, cridi terminate() sobre el fil blocat i el substitueixi. Comprova el comportament amb un fil que executi while (true) {}.

Amb 4 fils incrementant el mateix Int32Array sobre SharedArrayBuffer 100 000 vegades cadascun, compara el resultat fent servir comptadors[0] += 1 davant d'Atomics.add(comptadors, 0, 1). Explica la diferència.

Exercici 1. En repòs, /ping dona un p99 de 2-4 ms. Durant /bloquejar, totes les peticions a /ping s'acumulen i el p99 puja a diversos segons: exactament la durada del càlcul síncron. L'histograma mostra un max gairebé idèntic a aquella durada, perquè el bucle no va fer ni una volta. La lectura correcta és que /ping no té cap problema: el problema és un veí sorollós al mateix fil. És l'argument sencer d'aquesta lliçó en 30 línies de codi.

Exercici 2. Dins del setTimeout d'executar, es localitza el fil amb this.fils.find((f) => f.tascaActual === idTasca), es retira del pool, es crida await filPenjat.terminate() —que mata el fil encara que estigui en bucle— i se'n crea un de nou abans de rebutjar la promesa. Amb while (true) {} al fil, sense terminate() la plaça del pool es perd per sempre i després de N tasques penjades el pool queda inutilitzable. Amb terminate(), el pool es recupera sol. Nota: terminate() mata el fil de manera immediata i no hi ha aturada ordenada possible a dins.

Exercici 3. Amb comptadors[0] += 1 el total esperat és 400 000 però l'observat ronda les 120 000-250 000, i varia a cada execució. El motiu és que += són tres passos (llegir, sumar, escriure) i dos fils poden llegir el mateix valor i escriure el mateix resultat, perdent un increment. Amb Atomics.add el total és exactament 400 000, sempre: l'operació és indivisible a nivell de CPU. La moralitat és doble: la memòria compartida introdueix una classe d'errors que en JavaScript no existia, i aquests errors són no deterministes, de manera que les teves proves del mòdul 9 poden passar mil vegades i fallar en producció la nit de l'estrena.

Hem convertit un blocatge de 4,18 segons en un retard d'11 mil·lisegons. Hem mesurat el problema amb monitorEventLoopDelay, hem distingit amb claredat quan toca cluster (concurrència d'E/S) i quan fils (treball de CPU), hem entès què viatja entre fils amb el clonatge estructurat i què no, hem après a transferir en comptes de copiar i a compartir memòria amb Atomics sense obrir la porta a condicions de carrera, i hem construït src/treballadors/generar-entrades.js i src/treballadors/pool.js amb cua, reutilització, temps límit i recuperació davant d'errors. També hem après els límits: els fils no acceleren la tasca, només l'aparten; no serveixen per a E/S; no compensen per a feina trivial; i competeixen pels mateixos nuclis que els treballadors de cluster, cosa que obliga a dimensionar amb cap.

I queda una peça fora de lloc. Generar el PDF ja no bloqueja, però l'organitzador de l'Auditorio Ribera continua esperant quatre segons i mig amb la petició HTTP oberta que acabi. Si a més cal enviar per correu aquelles 500 entrades, l'espera es torna absurda. La resposta no és un fil més ràpid: és no esperar. A la lliçó següent, Memòria Cau i Cues de Treball amb Redis, traurem la feina pesada fora del procés, respondrem 202 Accepted amb un identificador de treball, guardarem a la memòria cau el catàleg que avui es recalcula a cada petició, i de passada saldarem el deute que va deixar la lliçó 10-01: sessions i límits de peticions compartits entre tots els treballadors.