Der Node-Prozess, der jede Locale behielt
Vue SSR renderte Russisch und allokierte trotzdem die en- und de-Dateien. Das Isolat wuchs mit jeder Seite.
Der vue-Container lag nach einem ruhigen Morgen bei 700 MB. Kein Leak im App-Code. Der SSR-Entry importierte bei jedem Render das volle i18n-JSON für en, ru und de und wählte dann eine Locale. Node behielt die anderen zwei im Isolat. Ein langlebiger Prozess gab das nicht zurück.
Das HTML-Payload wiederholte denselben Fehler. Der serialisierte State schickte alle drei Wörterbücher, damit der Client die Sprache ohne Navigation wechseln konnte. Niemand wechselte die Sprache ohne Navigation. Das extra JSON lag im Dokument und im Heap.
Das Problem war ein Isolat, das jede Locale hielt, obwohl die Locale schon in der URL sitzt. Besucher zahlten TTFB und ein fettes erstes Dokument. Ich brauchte eine Message-Tabelle pro Request und Recycle, wenn der Heap wuchs.
Was der Entry jetzt lädt
Der SSR-Server lädt Messages für die Locale des Requests, nicht für die ganze Site. Der Client hydriert nur diese Tabelle. Ein Sprachwechsel trifft eine neue URL und ein neues Dokument. So arbeitet der Router ohnehin.
Der Import des Locale-JSON ist dynamisch. Der Node-Prozess require die anderen zwei Dateien bei einem russischen Render nicht. Statischer Text ohne i18n bleibt im Server-Render und nicht im Hydrate-Payload.
- Statische Bereiche, die i18n nie hören, bleiben nur serverseitig.
- Formatierte Daten liegen im serialisierten State. Der Client rechnet sie nicht bei mount neu.
- Der vue-Prozess recycelt nach einer Speichergrenze, dieselbe Idee wie pm.max_requests bei PHP-FPM.
Der Heap eines warmen Workers lag bei etwa 180 MB. Das erste HTML verlor die ungenutzten Wörterbücher. Hydration-Warnungen durch Locale-Mismatch bei Daten gingen mit.
Was ich daraus mitnehme
SSR, der jede Locale importiert, ist ein Leak mit Termin. Das Isolat vergisst ungenutztes JSON nicht.
Sprachwechsel ohne Navigation war kein Produkt, das ich hatte. Drei Wörterbücher dafür waren im Design gratis und im Dokument teuer.
Den Node-Prozess recyceln. Langlebiges SSR ist PHP-FPM ohne max_requests, solange ich keine Grenze setze.