Paper Server Performance optimieren: Erst messen, dann ändern

Ein Paper-Server wird nicht dadurch schnell, dass möglichst viele Werte aus irgendeiner Optimierungsliste kopiert werden. Gute Performancearbeit beginnt mit einem reproduzierbaren Problem und Messdaten.

TPS und MSPT richtig lesen

Minecraft zielt auf 20 Ticks pro Sekunde. Ein Tick hat damit rechnerisch 50 Millisekunden Zeit. Paper dokumentiert, dass ein Server ab mehr als 50 ms pro Tick seine Zielrate nicht mehr halten kann. TPS sagt dir also, dass ein Problem besteht; MSPT zeigt, wie viel Zeit ein Tick benötigt.

spark statt blindem Tuning

Paper integriert seit Minecraft 1.21 den Profiler spark. Für eine Messung während eines Problems kannst du beispielsweise einen zeitlich begrenzten Profiling-Lauf starten:

/spark profiler start --timeout 600

Der Report zeigt, welche Codepfade und Aufgaben während der Messung Zeit verbrauchen. Profiling sollte stattfinden, während das Problem tatsächlich auftritt.

View Distance und Simulation Distance trennen

View Distance bestimmt, wie viele Chunks der Server an Clients sendet. Simulation Distance beeinflusst, in welchem Radius Spielmechaniken aktiv simuliert werden. Weniger ist nicht automatisch besser, kann aber bei vielen Spielern deutlich Last reduzieren.

Siehe View Distance und Simulation Distance.

Plugins einzeln als Ursache prüfen

Ein Plugin kann Last durch Datenbankzugriffe, Welt-Scans, Scoreboards, Platzhalter, Webhooks oder zu häufige Scheduler-Tasks erzeugen. Entferne nicht blind alles. Nutze spark, Logs und einen kontrollierten Testzustand.

Mehr RAM ist keine Universalantwort

Zu wenig Heap kann problematisch sein, aber ungenutzte Gigabytes beseitigen keine langsamen Ticks. CPU-Leistung, Weltaktivität, Plugins und Garbage Collection müssen gemeinsam betrachtet werden.

Spielmechaniken als Lastquelle

Viele Entities, Villager, Hopper, Redstone, große Farmen oder intensive Chunk-Generierung können die Last stark verändern. Deshalb ist die Spielerzahl allein kein verlässlicher Indikator für Serverbedarf.

Keine Konfigurationswerte ohne Wirkungskontrolle

Paper bietet zahlreiche globale und weltbezogene Optionen. Aendere jeweils wenige Werte, dokumentiere Ausgangszustand und Ergebnis und behalte die Spielmechanik im Blick. Ein niedrigerer Tick-Intervallwert für bestimmte Prozesse kann Gameplay verändern.

Performance-Workflow

1. Problem reproduzieren
2. TPS/MSPT bestätigen
3. spark-Report während des Problems erstellen
4. größte Verbraucher identifizieren
5. gezielte Änderung vornehmen
6. erneut unter vergleichbarer Last messen

CPU und Hauptthread verstehen

Viele zentrale Minecraft-Spielmechaniken müssen in einer festen Tick-Reihenfolge verarbeitet werden. Deshalb kann ein Server mit vielen CPU-Kernen trotzdem durch einen einzelnen besonders belasteten Thread limitiert sein. Das bedeutet nicht, dass weitere Kerne nutzlos sind: Netzwerk, Java-Laufzeit und Plugins können parallel arbeiten. Für die Kernsimulation ist jedoch starke Einzelthread-Leistung oft wichtiger als eine möglichst hohe Kernzahl.

Messwerte dokumentieren

Notiere vor Änderungen Spielerzahl, MSPT, relevante spark-Ergebnisse, View Distance und besondere Aktivitäten wie Chunk-Generierung oder Farmen. Ohne vergleichbare Ausgangslage kann eine scheinbare Verbesserung schlicht daran liegen, dass beim zweiten Test weniger Spieler online waren. Für langfristige Optimierung ist eine kleine Messhistorie wertvoller als eine Sammlung angeblicher Geheimwerte.