Minecraft-Leistung messen: Tickzeit statt Bauchgefühl

„Der Server laggt“ beschreibt eine Erfahrung, aber noch keine Ursache. Eine Person sieht verzögert erscheinende Blöcke, eine andere erlebt stockende Bewegungen und eine dritte wartet auf ein Menü. Diese Beobachtungen können zusammenhängen oder aus ganz verschiedenen Gründen entstehen. Für Lufox ist deshalb eine Untersuchung hilfreich, die zuerst das sichtbare Verhalten präzise beschreibt und erst danach technische Messwerte zuordnet. Wer sofort mehrere Einstellungen verändert, verliert leicht die Möglichkeit, den eigentlichen Auslöser zu erkennen.

Ein brauchbarer Anfang lautet beispielsweise: Beim schnellen Erkunden unbekannter Landschaft reagieren Blockaktionen zeitweise verzögert, während dieselbe Strecke nach einer Rückkehr flüssiger wirkt. Darin stecken bereits prüfbare Hinweise auf Situation, Handlung und Unterschied. Es ist noch keine Diagnose. Die Weltgenerierung könnte beteiligt sein, ebenso andere gleichzeitig laufende Aufgaben. Erst eine gezielte Messung kann zeigen, wo während des Problems tatsächlich Zeit verbraucht wird.

Tickzeit und Takt richtig einordnen

Der Server verarbeitet Spielzustände in wiederkehrenden Schritten. Bei dem üblichen Ziel von zwanzig Ticks pro Sekunde stehen rechnerisch fünfzig Millisekunden je Schritt zur Verfügung. Dauert die Arbeit regelmäßig länger, kann dieser Takt nicht gehalten werden. Die Tickzeit beschreibt damit eine andere Größe als die Anzahl tatsächlich erreichter Ticks. Ein stabiler Takt kann sowohl bei geringer als auch bei bereits erheblicher Auslastung bestehen. Paper: Scheduling

Deshalb lohnt sich der Blick auf Reserven. Ein Server, dessen typische Tickarbeit knapp unter der verfügbaren Zeit liegt, kann bei zusätzlichen Aufgaben schneller ins Stocken geraten als einer mit deutlichem Abstand. Eine einzelne Durchschnittszahl verschleiert dabei kurze Ausreißer. Für ein fühlbares Ruckeln können wenige sehr lange Schritte relevant sein, auch wenn der Durchschnitt über mehrere Minuten unauffällig aussieht.

Messwerte sollten entsprechend mit ihrem Zeitraum beschrieben werden. „Die Tickzeit war hoch“ ist ohne Dauer und Spielsituation wenig aussagekräftig. Besser ist eine Notiz, dass während einer bestimmten Erkundungsphase wiederholt lange Schritte auftraten und nach deren Ende zurückgingen. Zahlen erhalten erst durch diesen Bezug eine praktische Bedeutung. Für einen öffentlichen Artikel sind erfundene Beispielmessungen unnötig; der Prüfablauf lässt sich auch ohne scheinbar reale Benchmarkwerte erklären.

Server, Verbindung und Darstellung auseinanderhalten

Eine geringe Bildrate auf dem eigenen Gerät ist nicht dasselbe wie eine langsame Serversimulation. Wenn die Kamera beim Umsehen stockt, können Darstellungseinstellungen, aufwendige Modelle oder lokale Auslastung beteiligt sein. Wenn dagegen alle Spieler gleichzeitig verzögerte Blockreaktionen bemerken, lohnt sich eine Untersuchung des Servers. Eine schlechte Verbindung kann wiederum Antworten verzögern, obwohl beide Geräte ausreichend schnell arbeiten.

Die erste Diagnose sammelt deshalb mehrere Perspektiven. Tritt das Problem bei anderen Personen auf? Ist nur ein bestimmter Ort betroffen? Reagiert der Chat ebenfalls verzögert? Bleibt die Darstellung flüssig, während Spielaktionen warten? Diese Fragen ersetzen keine Messung, grenzen aber die wahrscheinlich betroffene Ebene ein. Ein Tickprofil wäre beispielsweise keine ausreichende Erklärung für eine ausschließlich lokale Darstellungsstörung.

Besonders bei eigenen Ressourcenpaketen und Modellen braucht Lufox diese Trennung. Ein visuell aufwendiger Ort kann auf einem schwächeren Gerät schwer darstellbar sein, während der Server wenig zusätzliche Arbeit hat. Umgekehrt kann ein unscheinbares Menü eine langsame Datenabfrage auslösen. Das sichtbare Ausmaß eines Effekts ist deshalb kein zuverlässiger Maßstab für seine technische Belastung.

Eine Messfrage formulieren

Vor dem Profiling wird eine konkrete Frage aufgeschrieben. Im Beispiel lautet sie: Entstehen die beobachteten Verzögerungen hauptsächlich während der Erzeugung neuer Landschaft oder auch auf bereits besuchten Strecken? Daraus ergeben sich zwei Vergleichsfahrten. Eine führt in einen vorbereiteten Bereich, die andere unter kontrollierten Bedingungen in einen bisher unbesuchten. Bewegungsart und beteiligte Personen bleiben möglichst ähnlich.

Ein zweites Beispiel betrifft ein Inventarmenü. Hier könnte die Frage lauten, ob häufiges Öffnen und Schließen über längere Zeit immer mehr Arbeit erzeugt. Der Lufox-Quelltext beendet beim Schließen eines eigenen Menüs dessen Auffrischung. Das ist eine relevante vorhandene Maßnahme, aber noch kein Beweis dafür, dass sämtliche Aufgaben aller Menüs korrekt enden. Ein gezielter Test betrachtet deshalb die Entwicklung über wiederholte Bedienungen.

Die Frage sollte so eng sein, dass ein Ergebnis eine Entscheidung erlaubt. „Ist der Server schnell?“ ist zu allgemein. „Bleibt die Zahl aktiver Aktualisierungsaufgaben nach hundert abgeschlossenen Menüöffnungen wieder auf dem Ausgangsniveau?“ wäre technisch konkreter. Für den praktischen Betrieb kann die Beobachtung vereinfacht werden, solange der Zusammenhang erhalten bleibt: wiederholte Handlung, erwartete Rückkehr zum Ruheverhalten und messbarer Unterschied.

Den Profiler während des Problems einsetzen

Paper empfiehlt spark für Leistungsuntersuchungen und betont, dass das zu untersuchende Problem während der Aufnahme auftreten muss. Eine Aufnahme im ruhigen Zustand erklärt nur diesen ruhigen Zustand. Deshalb wird das Profiling mit der festgelegten Spielsituation verbunden. Das Team hält Beginn und Ende der auffälligen Phase fest, damit die Ergebnisse später sinnvoll zugeordnet werden können. Paper: Profiling

Ein kurzer beispielhafter Aufruf kann eine begrenzte Aufnahme starten. Die genaue Bedienung wird an der vorhandenen spark-Fassung geprüft. Der folgende Befehl stammt aus der dokumentierten Grundbedienung und ist keine Aussage darüber, dass er bereits auf Lufox ausgeführt wurde.

/spark profiler start --timeout 600

Die Aufnahme sollte weder beliebig kurz noch unnötig lang sein. Sie muss das Problem enthalten, ohne viele sachfremde Phasen zu vermischen. Für wiederkehrende kurze Ausreißer kann eine andere Auswertung sinnvoll sein als für eine dauerhaft langsame Situation. sparks eigene Befehlsdokumentation beschreibt die verfügbaren Optionen. Gewählt werden nur jene, die zur konkreten Frage beitragen. spark: Command Usage

Ergebnisse als Hinweise lesen

Ein Profil zeigt, wo beobachtete Ausführungszeit zugeordnet wurde. Ein großer Anteil an einer Stelle bedeutet nicht automatisch, dass diese Stelle fehlerhaft ist. Vielleicht erfüllt sie gerade die beabsichtigte Hauptaufgabe. Entscheidend ist, ob die Arbeit für die Spielsituation notwendig ist und ob sie in angemessenem Umfang erfolgt. Ein häufig aufgerufenes Verfahren kann durch die Zahl seiner Aufrufe auffallen, obwohl jeder einzelne Aufruf klein ist.

Bei einem Menüproblem wäre daher zu unterscheiden, ob eine einzelne Darstellung teuer ist oder ob unnötig viele Aktualisierungen stattfinden. Im ersten Fall könnte die Berechnung verbessert werden. Im zweiten Fall wäre die Begrenzung des Lebenszyklus entscheidend. Eine pauschale Senkung der Aktualisierungsrate kann zwar Symptome mildern, würde einen nie beendeten Auftrag aber nicht grundsätzlich aufräumen.

Ähnlich vorsichtig wird mit Datenbankzugriffen umgegangen. Eine lange Wartezeit kann aus einer aufwendigen Abfrage, einer blockierten Verbindung oder konkurrierenden Schreibvorgängen entstehen. Die sichtbare Methode ist dann der Ort des Wartens und nicht unbedingt dessen Ursprung. Eine gute Auswertung verbindet deshalb Profil, Ablauf und ergänzende Protokolle. Sie sammelt ausreichend Belege, bevor eine konkrete Ursache behauptet wird.

Eine Änderung mit einer Erwartung verbinden

Vor einer Optimierung wird notiert, welcher Messwert oder welches Verhalten sich verändern soll. Angenommen, eine Menüaktualisierung fragt unveränderte Informationen ständig neu ab. Ein Entwurf könnte diese Informationen für die Dauer einer geöffneten Ansicht zwischenspeichern und nur nach relevanten Änderungen erneuern. Die Erwartung lautet dann, dass weniger wiederholte Abfragen stattfinden, während angezeigte Änderungen weiterhin rechtzeitig sichtbar werden.

Diese Erwartung enthält bereits den notwendigen Gegencheck. Eine schnellere Oberfläche ist kein Erfolg, wenn sie falsche Guthaben oder alte Freischaltungen zeigt. Leistung und Korrektheit werden gemeinsam geprüft. Ebenso ist eine verringerte Sichtweite nur dann eine brauchbare Maßnahme, wenn die verbleibende Sicht zum Spielkonzept passt. Technische Entlastung hat einen Preis, der ausdrücklich bewertet werden sollte.

Pro Vergleich wird möglichst nur eine relevante Änderung vorgenommen. Werden gleichzeitig Weltgrenze, Pluginfassung und Laufzeitparameter verändert, ist eine Verbesserung schwer zuzuordnen. Für einen dringenden Betriebsfall kann ein größeres Maßnahmenpaket nötig sein. Dann wird offen dokumentiert, dass die Wirkung einzelner Bestandteile noch nicht getrennt belegt ist. Eine spätere kontrollierte Prüfung kann diese Unsicherheit verringern.

Den Vergleich unter ähnlichen Bedingungen wiederholen

Nach der Änderung wird derselbe Ablauf erneut gespielt. Startzustand, beteiligte Funktionen und ungefähre Dauer bleiben vergleichbar. Bei einer Erkundungsfrage ist darauf zu achten, dass die zweite Fahrt nicht allein deshalb leichter ist, weil die erste bereits Landschaft erzeugt hat. Für einen sauberen Vergleich kann eine getrennte Testwelt oder ein gezielt vorbereiteter Ausgangszustand erforderlich sein.

Auch Aufwärmeffekte werden berücksichtigt. Ein frisch gestarteter Prozess kann sich anders verhalten als einer, dessen häufig genutzte Daten bereits verfügbar sind. Daraus folgt nicht, dass jede Untersuchung ein wissenschaftliches Labor benötigt. Es genügt, offensichtliche Unterschiede zu benennen und die Aussage entsprechend zu begrenzen. „Unter diesem Testablauf geringer“ ist belastbarer als „immer schneller“, wenn nur ein enger Fall geprüft wurde.

Der Vergleich betrachtet außerdem Nebenwirkungen. Ein entfernter Aktualisierungsauftrag darf keine dauerhaft veraltete Anzeige hinterlassen. Eine begrenzte Suche darf wichtige Ergebnisse nicht stillschweigend ausschließen. Eine reduzierte Zahl aktiver Objekte darf keine Quest unlösbar machen. Die beobachtete Leistungsverbesserung wird deshalb zusammen mit den relevanten Spielhandlungen abgenommen und nicht isoliert als Zahl gefeiert.

Während einer Störung handlungsfähig bleiben

Nicht jede Untersuchung kann sofort vollständig durchgeführt werden. Wenn das Spiel deutlich beeinträchtigt ist, braucht das Team zunächst eine begrenzte Entlastung, etwa das vorübergehende Schließen eines neu eingeführten Angebots. Diese Maßnahme wird als solche dokumentiert. Sie ist noch kein Beweis, dass ausschließlich dieses Angebot die Ursache war. Anschließend lässt sich der betroffene Ablauf in einer kontrollierten Umgebung genauer prüfen.

Hilfreich ist ein vorher festgelegtes Abbruchkriterium für Tests im laufenden Betrieb. Sobald gewöhnliche Spielhandlungen deutlich beeinträchtigt werden, endet die absichtlich erzeugte Zusatzlast. Die Untersuchung soll Erkenntnisse liefern und nicht durch immer stärkere Belastung einen möglichst spektakulären Fehler erzwingen. Ein kleiner reproduzierbarer Fall ist für die weitere Arbeit meist wertvoller.

Ein kleines Leistungsprotokoll führen

Für Lufox kann eine kurze Notiz je Untersuchung genügen. Sie enthält die sichtbare Störung, die Messfrage, den getesteten Ablauf, die Änderung und das Ergebnis. Dazu kommt ein Verweis auf die intern aufbewahrte Aufnahme. Personenbezogene oder betriebliche Details werden nicht unnötig veröffentlicht. Das Protokoll dient der Wiederholbarkeit und der Zusammenarbeit, nicht dem Sammeln möglichst umfangreicher Rohdaten.

Mit der Zeit entsteht daraus ein nützliches Gedächtnis. Wenn ein ähnliches Problem später erneut auftritt, kann das Team prüfen, ob die frühere Ursache wieder vorhanden ist oder lediglich dasselbe Symptom entsteht. Diese Unterscheidung verhindert, dass alte Maßnahmen reflexartig wiederholt werden. Ein neues Plugin oder eine veränderte Spielweise kann denselben Eindruck auf einem anderen Weg erzeugen.

Eine gute Leistungsarbeit endet deshalb mit einer überprüften Aussage und einer benannten Grenze. Die konkrete Situation wurde verbessert, die wichtigen Spielhandlungen funktionieren weiterhin und verbleibende Unsicherheiten sind bekannt. Tickzeiten helfen dabei, den Zustand der Serversimulation präziser zu verstehen. Ihren Wert erhalten sie jedoch erst durch eine klare Frage und einen nachvollziehbaren Vergleich. So wird aus dem allgemeinen Gefühl von Ruckeln eine Aufgabe, die sich gezielt bearbeiten lässt.

Eine abgeschlossene Untersuchung kann auch ergeben, dass die vermutete Ursache nicht bestätigt wurde. Dieses Ergebnis bleibt nützlich, wenn der geprüfte Ablauf beschrieben ist und die nächste Messfrage dadurch enger gefasst werden kann.