vjrj
56f53e2c23
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.
51 lines
1.9 KiB
JavaScript
51 lines
1.9 KiB
JavaScript
/* eslint-disable import/no-absolute-path */
|
|
|
|
// Telemetría de la unión de suscripciones (fase 12).
|
|
//
|
|
// Hasta ahora la única señal de que la unión iba mal era que el mapa se quedaba
|
|
// viejo: los fallos del worker se registraban con console.error y ahí morían. Lo
|
|
// que se manda a GlitchTip es deliberadamente poco: un aviso cuando una unión
|
|
// tarda más de lo que el banco de carga considera sano, otro cuando hay que
|
|
// degradar la geometría por tamaño, y los fallos. Las uniones normales solo
|
|
// dejan una línea de log.
|
|
|
|
import * as Sentry from '@sentry/node';
|
|
import { Meteor } from 'meteor/meteor';
|
|
import ravenLogger from '/imports/startup/server/ravenLogger';
|
|
|
|
// Medido en bench/union-bench.js: 10.000 suscripciones repartidas por España son
|
|
// ~40 s. Pasar del minuto significa o mucha más gente, o una distribución que no
|
|
// se solapa (el caso caro), o algo que se ha torcido. En cualquiera de los tres
|
|
// casos queremos enterarnos.
|
|
const DEFAULT_SLOW_MS = 60 * 1000;
|
|
|
|
const slowMs = () => (
|
|
(Meteor.settings.private && Meteor.settings.private.unionSlowMs) || DEFAULT_SLOW_MS
|
|
);
|
|
|
|
const unionTelemetry = {
|
|
computed({ kind, isPublic, subs, ms, bytes, degraded }) {
|
|
const scope = isPublic ? 'public' : 'private';
|
|
const line = `subsUnion ${kind} ${scope}: ${subs} subs, ${Math.round(ms)} ms, ${bytes} bytes${degraded ? ` (degradada: ${degraded})` : ''}`;
|
|
console.log(line);
|
|
|
|
if (ms > slowMs()) {
|
|
Sentry.captureMessage(`subsUnion lenta: ${Math.round(ms / 1000)} s con ${subs} suscripciones`, {
|
|
level: 'warning',
|
|
extra: { kind, scope, subs, ms, bytes }
|
|
});
|
|
}
|
|
if (degraded) {
|
|
Sentry.captureMessage(`subsUnion degradada por tamaño: ${degraded}`, {
|
|
level: 'warning',
|
|
extra: { kind, scope, subs, ms, bytes, degraded }
|
|
});
|
|
}
|
|
},
|
|
|
|
failed(error, context) {
|
|
ravenLogger.log(error, context);
|
|
}
|
|
};
|
|
|
|
export default unionTelemetry;
|