Renders ein Fünftel schneller: gemessen statt geschätzt

Ein Render ist eine Kette: Seite lesen, Storyboard schreiben, Website filmen, Stimme aufnehmen und dann den Film Bild für Bild mit Remotion zusammensetzen. Bei einem typischen 19,5-Sekunden-Film dauerte der ganze Auftrag 122 Sekunden, und 108 davon gehörten dem Compositor. Alles andere zusammen war kaum der Rede wert.

Die Geschwindigkeit des Compositors hängt davon ab, wie viele Bilder der Browser gleichzeitig malt. Am selben Film haben wir verschiedene Worker-Zahlen gemessen:

• ein Bild-Worker: 55 Sekunden;
• zwei Worker: 33 Sekunden;
• drei Worker: 25 Sekunden;
• vier Worker: 23 Sekunden.

In Produktion liefen zwei. Die Kurve zeigt drei als den Punkt, der sich lohnt: ein großer Gewinn gegenüber zwei und fast nichts mehr durch einen vierten.

Warum zwei? Speicher. Jeder Bild-Worker ist ein Browser-Tab mit dem Film, seinen Bildern und seinen Videodecodern, und Renders laufen auf Cloud Run mit fester Speichergröße. Irgendwann waren zwei Worker als sichere Zahl festgelegt worden. Niemand hatte nachgesehen, was die Maschine tatsächlich brauchte.

Also haben wir nachgesehen. Das Monitoring der Plattform führt für jeden Render eine Speicherreihe, und wir haben ihr 99. Perzentil über vierzehn Tage gelesen. Die Renders lagen in der Spitze bei 61 % ihrer 8 GiB, etwa 4,9 GiB, und drei Gigabyte blieben in zwei Wochen echter Filme unberührt. Das Limit, das wir respektiert hatten, war eines, dem wir nie nahegekommen waren.

Die neue Maschine hat 4 vCPU, 12 GiB und drei Bild-Worker. Unser Speichermodell sagte eine Spitze bei 44 % der neuen Größe voraus statt bei 61 %.

Beim Lesen der Konfiguration fanden wir eine einzige Einstellung mit zwei Aufgaben. Sie bestimmte sowohl, wie viele Bilder in einem Render parallel gemalt werden, als auch, wie viele ganze Renders ein Warteschlangen-Worker gleichzeitig annehmen würde.

Heute läuft jeder Render für sich und endet dann, also kam die zweite Bedeutung nie zum Tragen. Würde die Warteschlange aber eines Tages eingeschaltet, hätte eine Maschine, die auf drei parallele Bilder eingestellt ist, drei ganze Filme auf einmal angenommen. Die Warteschlange hat jetzt ihre eigene Einstellung, die bei einem Film zur Zeit bleibt. Ein Name, eine Bedeutung ist die billigste Sicherheit, die es gibt.

Außerdem nennen jetzt alle Dokumente, die die Maschine beschreiben, dieselbe Größe, damit die nächste Person, die sie einstellt, von der Wirklichkeit ausgeht.

Eine Vermutung, die aufgeschrieben wird, gilt bald als Tatsache. Deshalb sichert ein Test die neue Konfiguration und lässt den Build scheitern, sobald eine dieser Bedingungen nicht mehr stimmt:

• drei Worker passen mit 30 % Reserve in den angegebenen Speicher;
• nie mehr Bild-Worker als Kerne, und ein Kern bleibt für den Video-Encoder frei;
• das Zeitlimit deckt den längsten Film, den man bestellen kann, großzügig ab;
• jede Datei, die die Maschine beschreibt, nennt die tatsächlich eingesetzte Größe.

Wir haben auch ein Experiment festgehalten, das nichts änderte, damit es niemand wiederholt. Ein dreifacher Video-Cache bei einem Film, der ihn gezielt belastet, ergab 64,3 Sekunden statt 64,2, bei identischem Ergebnis, also behält der Cache seine Größe.

Ein Benchmark auf einem Laptop und zwei Wochen Messwerte sind eine Prognose, kein Ergebnis. Deshalb haben wir noch in derselben Nacht beides an echten Renders geprüft.

Siebzig Renders von 20- bis 40-Sekunden-Filmen mit zwei Workern lagen im Schnitt bei 5,93-facher Echtzeit. Die ersten vier mit drei Workern lagen bei 4,75-facher Echtzeit: etwa 20 % schneller, jeder der vier schneller als mindestens 77 % der siebzig. Kleine Stichprobe, klare Richtung.

Der Speicher erreichte in der Spitze 42 % der 12 GiB, also 5,04 GiB, bei 5,32 GiB, die unser Modell vorhergesagt hatte. Das Modell rechnet eher pessimistisch, und das ist die richtige Art, sich zu irren, wenn die Alternative ein Render ist, dem der Platz ausgeht. Es bleibt also, mit einer Regel mehr im Test: Das Modell darf nie weniger vorhersagen, als echte Filme danach brauchen. Mehr darüber, wie Filme entstehen, liest du auf der Funktionsseite.