Von Spigot zu Paper — und warum ich anfing, TPS zu messen

Nach dem Speicherproblem im Frühjahr lief mein Server stabil, aber er fühlte sich nicht gut an. Mobs ruckelten, Redstone hakte, und wenn zwei Leute gleichzeitig größere Flächen abbauten, hatte man kurz das Gefühl, im Wasser zu laufen. Alles funktionierte, nichts war flüssig.

Im Forum las ich immer wieder denselben Rat: „Nimm Paper." Ich habe wochenlang gezögert, weil ich dachte, das sei ein anderes Spiel, eine Art Mod-Plattform, bei der Plugins neu geschrieben werden müssten. Beides ist falsch.

Was Paper eigentlich ist

Die Kette ist so: Vanilla ist Mojangs Server. CraftBukkit setzt darauf und bringt eine Schnittstelle für Plugins mit. Spigot setzt auf CraftBukkit und optimiert. Paper setzt auf Spigot und optimiert deutlich mutiger — mit Änderungen, die manchmal winzige Abweichungen vom Vanilla-Verhalten bedeuten, dafür aber spürbar mehr Leistung bringen.

Das Wichtigste für den Umstieg: Alles, was auf Spigot lief, läuft auf Paper. Der Wechsel ist ein Dateitausch.

# Server stoppen
# Sicherung anlegen (immer, siehe der Eintrag über meinen ersten Datenverlust)
mv spigot-1.14.4.jar spigot-1.14.4.jar.alt
# paper-1.14.4.jar herunterladen und in die Startzeile eintragen
java -Xmx6G -Xms6G -jar paper-1.14.4.jar nogui

Beim ersten Start legt Paper zusätzliche Konfigurationsdateien an, und genau die sind der eigentliche Gewinn. Dort steht, wie oft entfernte Truhen aktualisiert werden, wie viele Mobs pro Chunk erlaubt sind, wie weit Redstone-Ketten laufen dürfen, ab wann Gegenstände auf dem Boden zusammengefasst werden. Sachen, die man auf Vanilla schlicht nicht einstellen kann.

Die Zahl, um die sich alles dreht

Der Satz, der bei mir wirklich etwas verändert hat, war der hier: Ein Minecraft-Server rechnet 20 Mal pro Sekunde. Jeder dieser Durchläufe heißt Tick, und in einem Tick passiert alles: Mobs bewegen sich, Pflanzen wachsen, Redstone schaltet, Spieler werden bewegt, Chunks werden geladen.

Ein Tick hat also 50 Millisekunden Zeit. Braucht er länger, kommt der nächste zu spät, und die Rate fällt unter 20. Das ist der Wert, den man mit /tps abfragt:

> tps
TPS from last 1m, 5m, 15m: 19.87, 20.0, 20.0

Und hier war meine große Erkenntnis: Der Server wird nicht langsamer, er wird seltener. Bei 10 TPS läuft die Spielwelt in halber Geschwindigkeit — Öfen brauchen doppelt so lange, Mobs bewegen sich zäh, aber der eigene Blick bleibt flüssig, weil den der Client zeichnet. Deshalb fühlt sich ein überlasteter Server so seltsam an: Es sieht flüssig aus, nur die Welt reagiert nicht richtig.

Sobald ich das verstanden hatte, konnte ich zum ersten Mal gezielt suchen. Nicht mehr „der Server ist langsam", sondern: Welcher Vorgang frisst so viel Zeit, dass 50 Millisekunden nicht reichen?

Wohin die Zeit bei mir ging

Mit dem Bericht aus /timings und Paper als Unterbau habe ich dann drei Dinge gefunden, die zusammen den größten Teil ausmachten.

Mobs. Wir hatten aus Spaß eine Kuhfarm gebaut, in der irgendwann über zweihundert Tiere standen. Jedes davon wird jeden Tick bewegt, prüft seine Umgebung, sucht Wege. In Papers Konfiguration lässt sich begrenzen, wie viele Tiere pro Chunk existieren dürfen, und die Wegfindung entfernter Mobs lässt sich drosseln. Allein das brachte mehrere Millisekunden pro Tick.

Gegenstände auf dem Boden. Nach einer größeren Sprengung liegen schnell tausend Einzelobjekte herum, jedes mit eigener Physik. Paper kann gleiche Gegenstände in der Nähe zusammenfassen. Aus 800 Objekten wurden 40.

Ein Plugin, das jeden Tick alle Spieler durchgeht. Das war eine kleine Erweiterung, die einen Scoreboard-Text aktualisierte. Zwanzig Mal pro Sekunde. Für eine Anzeige, die sich alle paar Sekunden ändert. Ich habe sie gegen etwas ausgetauscht, das einmal pro Sekunde aktualisiert — niemand hat den Unterschied bemerkt, außer den Timings.

Was der Wechsel nicht war

Ich will die Sache nicht größer machen, als sie war. Paper hat mir keine drei Gigabyte Speicher zurückgegeben und aus einem überlasteten Heimrechner keine Serverfarm gemacht. Der Rechner unter meinem Schreibtisch blieb ein Rechner unter meinem Schreibtisch.

Was sich geändert hat, war meine Perspektive. Vorher war „der Server ruckelt" ein Zustand, den man hinnimmt oder mit mehr Hardware bekämpft. Danach war es eine Frage mit einer messbaren Antwort: Welcher Vorgang braucht wie viel von meinen 50 Millisekunden?

Diese Frage lässt sich auf fast alles übertragen. Ein Webserver hat kein Tick-Budget, aber er hat eine Antwortzeit, und die setzt sich genauso aus Einzelposten zusammen. Ein Discord-Bot ebenso. Der Reflex, zuerst nach der Zahl zu suchen, die das Budget beschreibt, stammt bei mir aus diesem Herbst.

Die Einstellungen, die tatsächlich etwas gebracht haben

Damit dieser Eintrag praktisch nutzbar bleibt: Das sind die Stellschrauben, die bei mir gemessen den größten Unterschied gemacht haben, in dieser Reihenfolge.

Sichtweite senken. Der größte Hebel überhaupt, und der einzige, den Spieler bemerken könnten — bei uns hat es niemand gemerkt, weil die Basis in einem Tal lag. Auf Servern mit weiter Sicht ist es der schmerzhafteste Kompromiss.

Eine Weltgrenze setzen. Weltgenerierung ist das Teuerste, was ein Server tut. Eine Grenze verwandelt eine unendliche Karte in eine endliche und beendet damit die Sorte Auslastungsspitze, die auftritt, wenn jemand mit einem Boot Richtung Horizont fährt.

Grenzen für Tiere pro Bereich. Aus einer Farm mit zweihundert Tieren wird eine mit vierzig, und niemand vermisst die anderen hundertsechzig — außer der Tick-Zeit.

Gegenstände am Boden zusammenfassen. Nach jeder Sprengung, nach jedem Kampf, nach jedem Baumfällen liegen hunderte Einzelobjekte herum. Zusammengefasst sind es ein paar Dutzend.

Was nichts gebracht hat, obwohl es in jeder Anleitung steht: an der Speicherkonfiguration zu drehen, ohne ein Speicherproblem zu haben. Das war bei mir reine Beschäftigung.

Die Sache mit den fertigen Konfigurationen

Ein Punkt, der mir wichtig ist, weil er über Minecraft hinausgeht.

Es kursieren fertige Konfigurationsdateien, die auf maximale Leistung getrimmt sind. Sie funktionieren, sie sind schnell, und sie enthalten Einstellungen, die Spielmechaniken verändern — Wachstum in nicht geladenen Bereichen, Reichweite von Redstone-Signalen, Verhalten von Mobs.

Wer sie übernimmt, ohne sie zu lesen, hat einen schnellen Server mit unerklärlichen Eigenheiten. Und wenn drei Wochen später eine Farm nicht mehr funktioniert, sucht man den Fehler in der Farm.

Meine Regel daraus: Jede Einstellung, die in meiner Konfiguration steht, muss ich in einem Satz erklären können. Wenn ich das nicht kann, steht sie auf Standard. Das gilt für Spielserver genauso wie für Datenbanken, Webserver und alles andere, wo man fremde Konfigurationen übernehmen kann.

Für alle, die vor demselben Wechsel stehen

• Vorher sichern. Paper schreibt beim ersten Start Konfigurationen und kann Weltdaten anfassen. Der Rückweg ist nur mit Sicherung entspannt.
• Nicht alles auf einmal umstellen. Erst tauschen, ein paar Tage laufen lassen, dann an den neuen Stellschrauben drehen. Sonst weiß man hinterher nicht, welche Änderung was gebracht hat.
• Vorher und nachher messen. Zehn Minuten /timings vor dem Wechsel, zehn danach. Ohne Vergleichswert ist jede Optimierung Gefühlssache.
• Nicht blind Konfigurationen aus dem Internet übernehmen. Es kursieren Dateien, in denen alles auf Maximalleistung getrimmt ist — inklusive Einstellungen, die Farmen kaputtmachen oder Redstone-Bauten stilllegen. Jede Änderung sollte man erklären können.

Der letzte Punkt hat mich damals mehr Nerven gekostet als der ganze Rest. Ich hatte eine solche Datei übernommen, und drei Wochen später funktionierte die Kürbisfarm eines Freundes nicht mehr. Ursache war eine Einstellung, die Wachstumsvorgänge in nicht geladenen Chunks unterdrückt. Der Fehler war nicht die Einstellung — der Fehler war, dass ich sie nicht kannte, obwohl sie in meiner eigenen Konfiguration stand.