Zehnmal mehr Vorlagen und Renders, die aufräumen

Jede Motion-Vorlage ist eine kleine React-Komponente mit einer eigenen Beschreibung der Felder, die sie annimmt. 664 davon geben TypeScript Hunderte neue Formen zu prüfen und dem Build Hunderte neue Dateien zu kompilieren.

Das ist ein gutes Problem: Das Produkt ist reicher geworden. Aber Werkzeuge haben Standardgrenzen, und Node gibt jedem Prozess eine feste Menge Arbeitsspeicher, solange man nichts anderes sagt. Unser Typcheck und unser Produktions-Build waren schlicht über diese Menge hinausgewachsen. Unsere Releases gehen erst raus, wenn jede Prüfung bestanden ist, also wartete die neue Bibliothek an diesem Tor, bis die Prüfungen durchlaufen konnten.

Am einfachsten wäre es gewesen, den Speicher von Node überall zu erhöhen. Das haben wir bewusst nicht getan, denn der Webdienst, der deine Anfragen beantwortet, hat sein eigenes Limit, und mehr Spielraum dort würde eines Tages nur ein langsames Leck verdecken.

Der zusätzliche Platz geht deshalb an genau drei Stellen:

• der Typcheck bringt seinen eigenen, größeren Spielraum mit;
• die automatischen Prüfungen vor jedem Release setzen ihn für ihre Schritte;
• der Image-Build erhöht ihn nur für den Build-Befehl, der danach laufende Dienst bleibt unverändert.

Damit liefen die Prüfungen durch, und die Motion-Bank ging noch am selben Tag live. Dazu kam eine Gewohnheit: Wenn eine Bibliothek um Hunderte Dateien wächst, messen wir den Speicherbedarf des Builds vor dem Release, nicht danach.

Die zweite Aufgabe betraf den Plattenplatz. Bevor Remotion ein Video zeichnet, packt es den Code des Videos in ein Bundle, einen einzelnen Ordner, aus dem der Renderer liest. Dieser Ordner ist etwa 0,9 GB groß, landet im temporären Verzeichnis des Systems, und nichts entfernt ihn, wenn die Arbeit erledigt ist.

Dort, wo unsere Videos entstehen, spielt das nie eine Rolle. Jeder Render läuft in einem eigenen, kurzlebigen Job, und wenn der Job endet, verschwindet seine Platte mit ihm. Auf langlebigen Rechnern dagegen bleibt jedes Bundle liegen. 664 Vorlagen in drei Formaten zu prüfen hieß viele Renders an einem Tag auf unserem Entwicklungsrechner, und die Ordner summierten sich schnell: 657 Stück, rund 42 GB.

Wir wollten einen Render, der nichts zurücklässt, egal wo er läuft. Also haben wir eine kleine Hilfsfunktion geschrieben, cleanupBundleOnExit, und jeden Aufruf des Bundlers damit umhüllt, im Render-Code und in jedem Skript, das bundelt.

• Sie läuft bei normalem Ende, bei einem expliziten Exit und bei Strg-C oder einem Stoppsignal.
• Sie entfernt nur einen Ordner, der wie ein Remotion-Bundle heißt und direkt im temporären Verzeichnis liegt, und kann daher nichts anderes berühren.
• Ein eigener Test prüft, dass jede Stelle, die bundelt, sie nutzt.

Einen Besen, der das ganze temporäre Verzeichnis nach Zeitplan leert, haben wir bewusst nicht gebaut. Dieser Ordner wird von allen anderen Programmen auf dem Rechner geteilt, und ein Werkzeug, das an einem geteilten Ort nach Muster löscht, ist genau das, das eines Tages das Falsche löscht. Jeder Prozess räumt jetzt nur auf, was er selbst angelegt hat, und sonst nichts.

Direkt siehst du davon nichts, und genau darum geht es. Die gestalteten Karten kamen an dem Tag ins Produkt, an dem sie fertig waren, und die Rechner, die jede Vorlage und jedes Video prüfen, behalten den Platz, den sie brauchen, um es morgen wieder zu tun.

Es heißt auch, dass wir die Bibliothek weiter ausbauen können. Jede neue Ladung Vorlagen kommt jetzt mit zwei schon beantworteten Fragen: Hat der Build genug Speicher dafür, und räumt jeder Render hinter sich auf? Für beides gibt es einen Test.

Keine der beiden Änderungen korrigierte einen Fehler in unserer Logik. Beide kamen von der Größe: Eine Bibliothek, die um Hunderte Komponenten wächst, verändert den Speicherbedarf eines Builds und den Platz, den ein Render hinterlässt. Ein Code-Review zeigt beides nicht; eine Messung schon.

Deshalb behandeln wir einen großen Sprung an Inhalten jetzt wie ein neues Feature: Wir messen, was er die Technik kostet, geben ihm genau dort Platz, wo er ihn braucht, und sorgen dafür, dass alles, was temporäre Dateien schreibt, sie auch wieder entfernt.