Schon wieder keine Downtime!
Jeden Tag denke ich über Downtime nach, warte darauf, dass sie endet und zeichne das Ergebnis auf.
Das letzte Mal, als ich das hier verfasst habe (Habt ihr den Devblog gelesen? Der ist richtig gut, versprochen), dauerte Tranquilitys automatischer Neustart am Wochenende ungefähr vier Minuten und 20 bis 40 Sekunden, was gerade so für eine kurze Teepause reichte. Anderthalb Jahre später beträgt die Dauer des automatischen Neustarts drei Minuten und 34 Sekunden – da muss man sich mit dem Tee schon mächtig beeilen (Die Zeit habe ich beim Schreiben dieses Devblogs gemessen). Angesichts der Fortschritte, die wir seit 2019 gemacht haben, ist eine Downtime beim automatischen Neustart von 3 Minuten und 30 bis 40 Sekunden heutzutage normal.
Ich könnte jetzt mithilfe dieses super wissenschaftlichen Diagramms aufzeigen, dass sich die Downtime um 50 bis 60 Sekunden verkürzt hat, was einer Verbesserung von 22,5 % im Zeitraum von 3. Dezember 2019 bis 3. Juli 2021 entspricht, und vorhersagen, dass es ab dem 19.
Dezember 2026 gar keine Downtime mehr geben wird, doch die Realität gestaltet sich komplizierter. Es gibt eine (weiche) untere Grenze von ca. drei Minuten, in denen drei Aktivitäten während der Downtime stattfinden: die Abschaltung, die Datenbankprozesse und das Hochfahren. Jede dieser Aktivitäten dauert ca. eine Minute, wenn wir nichts Wesentliches daran ändern, und die wesentlichste Änderung besteht immer noch darin, ganz ohne Downtime auszukommen. Die Downtime wird sich nicht auf viel weniger als 160 bis 200 Sekunden verkürzen lassen. Stattdessen muss es zunächst weniger Downtimes und schließlich keine mehr geben. Trotzdem wollte ich diesen Blog mit einem konkreten Beispiel dazu einleiten, wie sich die Downtime seit dem letzten Mal verkürzt hat. Und jetzt ist ein neues Keine-Downtime-Experiment für den 9. September geplant.
Dieses zweite Keine-Downtime-Experiment dient mindestens vier Zwecken:
- Es soll die Behebung der Probleme verifizieren, die beim letzten Experiment im Bereich der Live-Produktion entdeckt wurden
- Es soll verifizieren, dass sich seit dem letzten Mal weder der Code noch andere Funktionen verschlechtert haben und es soll weitere Fehler ermitteln
- Es soll die Speicherauslastung überwachen
- Es soll verifizieren, dass unsere Technologieplattform (über die ihr an späterer Stelle mehr erfahrt) nicht davon ausgeht, dass eine Downtime stattfindet
Ihr fragt euch also, was wir beim letzten Mal rausgefunden haben?
Zunächst einmal haben wir festgestellt, dass die Downtime ein Ereignis ist, das einen täglichen Neustart einleitet, von dem bestimmte Prozesse im Spiel abhängen. So können Timer von Strukturen, die 24 Stunden und länger laufen, ohne Downtime nicht enden und Corporations werden daran gehindert, an Fraktionskriegen teilzunehmen. Wir haben alle Probleme, die wir ermittelt haben und die uns gemeldet wurden, behoben. Jetzt möchten wir sie weiter verifizieren (natürlich haben wir sie getestet, aber unsere Testumgebung deckt nicht Tranquilitys Größe ab) und nach weiteren Problemen suchen.
Es wurden außerdem eine Zeitdesynchronisation (die wir behoben haben) sowie eine signifikante Speicherauslastung (die wir etwas verbessert haben) festgestellt. Die Zeitdesynchronisation war ein bekanntes Problem, aber beim letzten Experiment haben wir überprüft, ob sie Spielern am Ende von Tag 2 auffällt. Ziel ist eine Zeitdesynchronisation von maximal ± 0,5 Sekunden, doch bei neuerer Hardware stellten wir am Ende des Testlaufs eine Desynchronisation von 2,25 Sekunden fest.
An Tag 2 des ersten Keine-Downtime-Experiments im Jahr 2019 lag die Zeitdesynchronisation – erwartungsgemäß – bei 4,5 Sekunden. Als die Desynchronisation bei über drei Sekunden lag, fiel sie Spielern schließlich auf. Sie machte sich vor allem durch eine Art Modul-Lag bzw. eine Modulverzögerung bemerkbar, die auftrat, wenn der Client und der Knoten, der das Sonnensystem hostet, beim Modulzyklus deutlich voneinander abwichen. Die Zeitdesynchronisation liegt heute für gewöhnlich bei ± 1/100 einer Sekunde und damit unter dem maximalen Wert von ± 0,5 Sekunden.
Tranquility war schon immer sehr speicherintensiv. Um eine bessere Performance zu erreichen, vertrauen wir seit jeher darauf, Werte und Prozessdaten vorzuberechnen und die Ergebnisse zur späteren Verwendung zu speichern, anstatt die Werte später erneut berechnen zu müssen. So ging es bei den Projekten „Brain in a Box“ und „Dogma Rewrite“ im Jahr 2015 um das Berechnen und Speichern von Skills und deren Effekten (mit anderen Worten: die Gehirne der Charaktere) mit dem Ziel, die berechneten Ergebnisse zwischen Sonnensystemen zu übertragen, statt die Gehirne bei jedem Eintritt in ein neues Sonnensystem neu berechnen zu müssen. Außerdem leeren wir den Speicher nicht, da der Speicher des Cluster-Knotens sowieso jeden Tag zurückgesetzt wird, was beim täglichen Neustart passiert (Bitte beachten: Natürlich leeren wir nicht unseren DB-Cache-Speicher oder unseren Redis-Cache-Speicher. Während jeder Downtime wird beim Neustart lediglich der Cache-Speicher der Hauptsimulation geleert).
Die speicherintensivsten Knoten im Tranquility-Cluster sind jene für Charakterdienste, die die bereits erwähnten Gehirne speichern. Beim letzten Experiment lag ihre Auslastung am Ende von Tag 2 bei 75 %, was gerade so unsere maximale Betriebstoleranz von 80 % unterschritt. Würden wir das Cluster in einem Zustand betreiben, bei dem der erste Knoten bei 100 % Speichernutzung liegt, könnten wir Tranquility möglicherweise drei Tage (und vielleicht weitere sieben Stunden) lang laufen lassen, wenn man sich die Zahlen von 2019 anschaut. 2019 lag die Speicherauslastung an Tag 1 bei 55 %. Heutzutage liegt sie nur noch bei ca. 35 %, weshalb wir unsere Beobachtungen anpassen möchten.
Keine Downtime zu haben ist ein langfristiges Ziel, auf das all unsere technologischen Fortschritte ausgelegt sind. Wir arbeiten bereits seit einigen Jahren an einer EVE-Technologieplattform für Microservices und Message Bus und haben damit begonnen, die Plattform für eine Reihe von Funktionen zu nutzen. Jetzt wollen wir beobachten, wie sich dieses Ökosystem ohne Downtime im primären Spielcluster schlägt, und dabei sicherstellen, dass es nicht von einer täglichen Downtime ausgeht.
Wir sehen uns am Donnerstag, dem 9. September, wenn das zweite Experiment „Keine Downtime“ beginnt. Außerdem – genau wie beim letzten Mal – wird es bald ein Video geben. Ein derart heldenhafter Stunt erfordert eine Menge Anstrengung und Kraft.
