Paper-Config-Tuning: Einstellungen, die wirklich Performance bringen
Es vergeht keine Woche, ohne dass irgendwo in einem Discord jemand eine "optimierte Paper-Config" teilt, die deinen Server "doppelt so schnell" machen soll. Die Realität: Die Standardeinstellungen von Paper sind schon ziemlich gut, der meiste Gewinn steckt in einer Handvoll Stellschrauben, und der Rest so einer magischen Config verändert vor allem, wie sich dein Server spielt — nicht, wie schnell er ist. Deshalb in diesem Artikel: welche Einstellungen wirklich Performance bringen, in welcher Datei sie wohnen und warum du erst misst, bevor du an irgendetwas drehst.
Erst messen, dann drehen
Tuning ohne Messung ist Raten. Zum Glück ist Messen heute einfach: Aktuelle Paper-Versionen liefern den Profiler spark direkt mit. Mit /spark tps siehst du TPS und MSPT auf einen Blick, und mit /spark profiler startest du eine Messung, die zeigt, wohin die Zeit geht: Entities, Hopper, Weltgenerierung oder dieses eine Plugin. Die älteren Timings-Reports werden ausgemustert; spark ist der Nachfolger.
Wichtige Unterscheidung dabei: Niedrige FPS bei einem Spieler sind Client-Lag und lassen sich nicht mit Server-Configs lösen. Erst wenn die TPS unter 20 sinkt oder die MSPT dauerhaft Richtung 50 kriecht, hat dein Server wirklich zu kämpfen. Miss außerdem zu einem repräsentativen Zeitpunkt — an einem vollen Abend, nicht an einem leeren Dienstagmorgen — und heb die Messung auf. Nur dann kannst du nach einer Änderung sehen, ob sie wirklich etwas gebracht hat.
Die Config-Ebenen im Überblick
Paper baut auf Spigot auf, das wiederum auf Bukkit und Vanilla aufbaut. Jede Ebene hat ihre eigene Datei:
| Datei | Was dort wohnt |
|---|---|
server.properties | Die Vanilla-Basis: view-distance, simulation-distance, max-players, Welteinstellungen |
bukkit.yml | Spawn-Limits pro Mob-Kategorie, Autosave-Intervall |
spigot.yml | Entity-Activation-Range, mob-spawn-range, Hopper-Ticks, Merge-Radius |
config/paper-global.yml | Serverweite Paper-Einstellungen, etwa das Chunk-System |
config/paper-world-defaults.yml | Paper-Einstellungen pro Welt: Hopper-Verhalten, Spawn-Tweaks und vieles mehr |
Gut zu wissen: Einstellungen aus paper-world-defaults.yml kannst du pro Welt mit der Datei paper-world.yml im Ordner dieser Welt überschreiben.
Die Stellschrauben, die wirklich etwas tun
view-distance und simulation-distance
Der größte Hebel, beide in server.properties. View-distance bestimmt, wie viele Chunks ein Spieler zu sehen bekommt; simulation-distance bestimmt, in wie vielen Chunks die Welt wirklich lebt: Mobs bewegen sich, Pflanzen wachsen, Maschinen ticken. Simulieren ist viel teurer als Anzeigen. Der klassische Trick lautet daher: view-distance großzügig lassen (8 bis 10) und simulation-distance niedriger setzen (5 bis 7 auf einem vollen Server). Spieler sehen einen weiten Horizont, während dein Server nur einen Bruchteil dieser Chunks ticken muss. Wie du die View-Distance anpasst, steht in der Knowledgebase: die View-Distance anpassen.
Mob-Spawns
Die spawn-limits in bukkit.yml bestimmen, wie viele Mobs pro Kategorie um Spieler herum existieren dürfen; Monster stehen standardmäßig auf 70. Auf einem vollen Server kannst du da schrittweise runtergehen. In spigot.yml sollte mob-spawn-range im Gleichgewicht mit deiner simulation-distance bleiben, und Paper verteilt Spawns standardmäßig fair über die Spieler, sodass ein AFK-Spieler an einer Farm nicht alle Spawns schluckt. Aber Achtung: Zu aggressives Kürzen merkst du sofort im Gameplay — leere Nächte, stillstehende Farmen, verärgerte Spieler. Also kleine Schritte.
Hopper
Große Sortiersysteme und Farmen mit Tausenden Hoppern können ernsthaft auf deine Tick-Zeit drücken. In spigot.yml bestimmen ticks-per.hopper-transfer und ticks-per.hopper-check, wie oft Hopper arbeiten; sie leicht zu erhöhen bringt dann spürbar etwas, verändert aber das Timing bestehender Farmen und Sortiermaschinen. In paper-world-defaults.yml kannst du vollen Hoppern zusätzlich mit cooldown-when-full eine Pause gönnen. Miss zuerst, ob Hopper überhaupt dein Problem sind, bevor du hier etwas anfasst.
Chunks laden
Neue Chunks zu generieren ist eine der schwersten Aufgaben, die ein Server kennt. Paper hat in paper-global.yml Stellschrauben für das Chunk-System, aber der ehrliche Rat lautet: Lass die Finger davon, außer eine Messung schickt dich dorthin und du weißt, was du tust — die Standardwerte sind gut gewählt. Mehr Gewinn holst du aus einer Weltgrenze und dem Vorgenerieren von Chunks (siehe Weiterlesen) sowie aus schnellem Speicher: Chunks von NVMe zu laden merkst du schlicht im Spiel.
Vernünftige Defaults pro Servertyp
Kleiner Survival-Server (2 bis 10 Spieler): Lass fast alles auf Standard. Die Paper-Defaults sind dafür reichlich dimensioniert; hakt es trotzdem, liegt das eher an einer extremen Farm, einem schweren Plugin oder zu wenig RAM als an deiner Config. Stunden ins Tuning zu stecken lohnt sich hier selten.
Voller Community-Server (20+ Spieler): Nimm das als Startpunkt, nicht als Dogma:
view-distance8 undsimulation-distance6;spawn-limits.monstersschrittweise runter von 70;mob-spawn-rangepassend zu deiner simulation-distance;- Hopper-Einstellungen nur anpassen, wenn spark auf Hopper zeigt.
Führe Änderungen einzeln durch und miss nach jedem Schritt mindestens einen vollen Abend. Sonst weißt du nie, welche Schraube den Unterschied gemacht hat — oder welche Schraube etwas kaputtgemacht hat.
Vorsicht mit "magischen Configs" aus dem Internet
Zu diesen fertigen Optimierungs-Configs, die überall kursieren: Sei sparsam damit. Sie sind oft für ältere Versionen geschrieben, stellen Dutzende Einstellungen gleichzeitig um und schneiden vor allem Verhalten weg: weniger Mob-Spawns, anderes Redstone-Timing, Farmen, die stillschweigend nicht mehr laufen. Wird dein Server dadurch schneller, weißt du nicht, durch welche der vierzig Zeilen; geht etwas kaputt, auch nicht. Willst du trotzdem eine nutzen: Leg sie neben die Standardwerte, übernimm nur bewusst, was du verstehst, und ändere in kleinen Schritten. Die Paper-Defaults haben die Leute geschrieben, die die Serversoftware selbst bauen; "alles anders" ist selten eine Verbesserung.
Wenn Tuning nicht reicht
Zum Schluss die ehrliche Wahrheit: Eine Config kann keine Hardware herbeizaubern. Zu wenig RAM für deine Spielerzahl, ein Stapel schwerer Plugins oder langsamer Speicher lässt sich nicht mit YAML lösen. Zeigt spark Richtung Speicherdruck oder langsame Chunk-Speicherung, ist ein größeres Paket schlicht die bessere Investition. Bei MC-Node läuft jeder Minecraft-Server auf eigener Hardware mit NVMe-Speicher — gerade für Chunks ein spürbarer Unterschied — ab 0,50 € pro Monat, mit ca. 1,10 € pro GB RAM. Alles ist monatlich kündbar, eine Nummer größer ausprobieren und zurückskalieren, wenn es übertrieben war, geht also einfach.