Cuatro endurecimientos salidos del banco de carga (bench/union-bench.js), cada
uno con su número:
1. Unión en ÁRBOL en vez de en cadena. La cadena unía siempre contra un polígono
acumulado que no paraba de crecer. Con 1.000 suscripciones repartidas por el
mundo —el peor caso, círculos que no se solapan— eran 238 s; en árbol son
3,6 s, con un documento idéntico. Con datos realistas (España) 10.000
suscripciones bajan de 39,3 s a 23,5 s. test/server/calcUnionAsync.test.js
comprueba la equivalencia contra una referencia calculada en cadena.
2. 64 vértices por círculo en vez de 144, configurable con
`private.unionCircleSteps`. Con 10.000 suscripciones: 23,5 s → 10,0 s y el
pico de RSS de 777 MB → 421 MB. En pantalla un círculo de 64 lados sigue
siendo un círculo, y la capa de zonas es un adorno difuso; el host de
despliegue tiene 5,9 GB para todo el stack.
3. Timeout del worker (10 min por defecto, `private.unionWorkerTimeoutMs`). Un
worker que no contestaba dejaba la promesa colgada y con ella la cola entera:
`busy` se quedaba en true y no se volvía a calcular ninguna unión hasta
reiniciar, sin que nada fallase. Se reintenta una vez ante un error real,
nunca ante un timeout.
4. Cota de heap del worker (1 GB, `private.unionWorkerMaxHeapMb`), para que un
caso patológico muera con ERR_WORKER_OUT_OF_MEMORY —que esta capa convierte
en un rechazo, dejando la unión anterior intacta— en vez de que el kernel se
lleve por delante el proceso de Meteor.
Además unionTelemetry.js manda a GlitchTip las uniones que pasan de un minuto y
las que hay que degradar por tamaño, y registra duración/tamaño de cada una. El
único aviso de que la unión iba mal era, hasta ahora, que el mapa se quedaba
viejo.
Smoke REST byte-idéntico. 90 tests en verde.
Ejecuta el worker de producción contra suscripciones sintéticas realistas
(península, Canarias, Baleares; radios de 5 a 100 km) y mide lo que la fase 12
pide: duración del recreate completo y del incrementalAdd, retraso máximo del
event loop del proceso padre —que es donde vive DDP y por tanto la pregunta
real de "¿se congela la web?"—, tamaño del documento frente al límite de 16 MiB
y pico de RSS.
`--spread world` reparte las suscripciones por todo el mundo: es el peor caso
para el tamaño, porque casi no se solapan y la unión conserva un polígono por
suscripción en vez de fundirlos.
treeUnionWorker.js es una variante solo del banco (une en árbol en vez de en
cadena) para poder comparar estrategias con números antes de tocar el worker
de verdad. El worker de producción solo cambia en que ahora acepta `steps` por
workerData, con el mismo 144 de siempre por defecto.
The previous side-effect-import fix didn't work: the app's own npm deps
(installed by `meteor build`) live in programs/server/npm/node_modules,
a SIBLING of programs/server/assets, not an ancestor of it. Node's
require() only walks up parent directories looking for node_modules,
so require('@turf/circle') from the worker asset script could never
find it regardless of what gets imported elsewhere in the app — it
kept failing with "Cannot find module '@turf/circle'" even after that
fix was deployed.
calcUnionAsync.js (Meteor-compiled code, which already knows how to
locate the app's npm deps) now resolves the three turf package paths
itself and hands them to the worker via workerData; the worker
requires them by absolute path instead of bare specifier.
A full recreate() over 7k+ subscriptions takes ~20 minutes even in a
worker thread — fine for not blocking the site, but means a new zone
takes ages to show up on the map. Since union only grows when adding a
circle, a new subscription can just be merged into the union already
stored (one turf.union call) instead of rebuilding the whole chain.
changed/removed still trigger a full recreate() (union can't be
"subtracted" from safely), and incrementalAdd falls back to a full
recreate whenever the stored count isn't exactly one behind what's
expected, rather than risk merging into stale state. Both paths now
share one serialized queue (FIFO for adds, coalesced for recomputes)
so they never race on the same stored union.
The previous fix (yielding to the event loop between turf.union calls)
was not enough: once the merged polygon gets complex with thousands of
subscriptions, a single turf.union call can itself take seconds, and
yielding between iterations doesn't help when one iteration alone
blocks that long. Confirmed in staging: the site was still fully
unresponsive (Cloudflare 524, curl hanging 2+ minutes, healthcheck
failing) while a recompute ran.
Validation/decoration (addNoisy/noNoisy, cheap) stays on the main
thread; the actual circle+union chain now runs in a worker_thread
(private/workers/unionWorker.js, plain CommonJS so meteor build copies
it verbatim instead of compiling it) so the main event loop serving
DDP/HTTP is never blocked by it, regardless of how slow any single
turf call gets.
