Paper-config tuning: instellingen die echt performance opleveren
Er gaat geen week voorbij zonder dat iemand ergens in een Discord een "geoptimaliseerde Paper-config" deelt die je server "twee keer zo snel" zou maken. De werkelijkheid: de standaardinstellingen van Paper zijn al behoorlijk goed, de meeste winst zit in een handvol knoppen, en de rest van zo'n magische config verandert vooral hoe je server spéélt — niet hoe snel hij is. Daarom in dit artikel: welke instellingen echt performance opleveren, in welk bestand ze wonen, en waarom je eerst meet voordat je ergens aan draait.
Eerst meten, dan draaien
Tuning zonder meting is gokken. Gelukkig is meten tegenwoordig makkelijk: recente Paper-versies leveren de profiler spark standaard mee. Met /spark tps zie je TPS en MSPT in één oogopslag, en met /spark profiler start je een meting die laat zien wáár de tijd heen gaat: entities, hoppers, wereldgeneratie of die ene plugin. De oudere timings-rapporten raken uitgefaseerd; spark is de opvolger.
Belangrijk onderscheid daarbij: lage FPS bij een speler is client-lag en los je niet op met serverconfigs. Pas als de TPS onder de 20 zakt of de MSPT structureel richting de 50 kruipt, heeft je sérver het zwaar. Meet bovendien op een representatief moment — een drukke avond, niet een lege dinsdagochtend — en bewaar die meting. Alleen dan kun je na een wijziging zien of die echt iets opleverde.
De config-lagen op een rij
Paper bouwt voort op Spigot, dat weer voortbouwt op Bukkit en vanilla. Elke laag heeft een eigen bestand:
| Bestand | Wat er leeft |
|---|---|
server.properties | De vanilla-basis: view-distance, simulation-distance, max-players, wereldinstellingen |
bukkit.yml | Spawn-limieten per mobcategorie, autosave-interval |
spigot.yml | Entity-activation-range, mob-spawn-range, hopper-ticks, merge-radius |
config/paper-global.yml | Servergebrede Paper-instellingen, zoals het chunk-systeem |
config/paper-world-defaults.yml | Paper-instellingen per wereld: hopper-gedrag, spawn-tweaks en veel meer |
Handig om te weten: instellingen uit paper-world-defaults.yml kun je per wereld overschrijven met het bestand paper-world.yml in de map van die wereld.
De knoppen die echt iets doen
view-distance en simulation-distance
De grootste hefboom, allebei in server.properties. View-distance bepaalt hoeveel chunks een speler te zíén krijgt; simulation-distance bepaalt in hoeveel chunks de wereld echt leeft: mobs bewegen, gewassen groeien, machines tikken. Simuleren is veel duurder dan tonen. De klassieke truc is dan ook: view-distance ruim houden (8 tot 10) en simulation-distance lager zetten (5 tot 7 op een drukke server). Spelers zien een verre horizon, terwijl je server maar een fractie van die chunks hoeft te tikken. Hoe je de view-distance aanpast staat in de kennisbank: view-distance aanpassen.
Mob-spawns
De spawn-limits in bukkit.yml bepalen hoeveel mobs er per categorie rond spelers mogen bestaan; monsters staat standaard op 70. Op een drukke server kun je daar stapsgewijs mee omlaag. In spigot.yml hoort mob-spawn-range in balans te blijven met je simulation-distance, en Paper verdeelt spawns standaard eerlijk over spelers, zodat één AFK-speler bij een farm niet alle spawns opslokt. Maar let op: te agressief snijden merk je direct in de gameplay — lege nachten, farms die stilvallen, boze spelers. Kleine stapjes dus.
Hoppers
Grote sorteersystemen en farms met duizenden hoppers kunnen serieus op je tick-tijd drukken. In spigot.yml bepalen ticks-per.hopper-transfer en ticks-per.hopper-check hoe vaak hoppers werken; iets verhogen scheelt dan merkbaar, maar verandert wél de timing van bestaande farms en sorteermachines. In paper-world-defaults.yml kun je daarnaast volle hoppers rust gunnen met cooldown-when-full. Meet eerst of hoppers überhaupt jouw probleem zijn voordat je hier iets aanraakt.
Chunks laden
Nieuwe chunks genereren is een van de zwaarste taken die een server kent. Paper heeft in paper-global.yml knoppen voor het chunk-systeem, maar het eerlijke advies is: blijf daar vanaf tenzij een meting je erheen wijst én je weet wat je doet — de standaardwaarden zijn goed gekozen. Meer winst haal je uit een wereldgrens en het vooraf genereren van chunks (zie verder lezen), en uit snelle opslag: chunks laden vanaf NVMe merk je gewoon in het spel.
Sane defaults per servertype
Kleine survival-server (2 tot 10 spelers): laat vrijwel alles op standaard staan. De Paper-defaults zijn hier ruimschoots op berekend; hapert het toch, dan komt dat eerder door één extreme farm, een zware plugin of te weinig RAM dan door je config. Uren in tuning steken loont hier zelden.
Drukke community-server (20+ spelers): gebruik dit als startpunt, niet als dogma:
view-distance8 ensimulation-distance6;spawn-limits.monstersstapsgewijs omlaag vanaf 70;mob-spawn-rangein lijn met je simulation-distance;- hopper-instellingen alleen aanpassen als spark hoppers aanwijst.
Voer wijzigingen één voor één door en meet na elke stap minstens één drukke avond. Anders weet je nooit welke knop het verschil maakte — of welke knop iets kapotmaakte.
Pas op met "magische configs" van internet
Over die kant-en-klare optimalisatie-configs die overal rondgaan: wees er zuinig mee. Ze zijn vaak geschreven voor oudere versies, zetten tientallen instellingen tegelijk om en snijden vooral gedrag weg: minder mob-spawns, andere redstone-timing, farms die het stilletjes niet meer doen. Wordt je server er sneller van, dan weet je niet door welke van de veertig regels; gaat er iets kapot, dan ook niet. Wil je er toch een gebruiken: leg hem naast de standaardwaarden, neem alleen bewust over wat je begrijpt en verander in kleine stapjes. De Paper-defaults zijn geschreven door de mensen die de serversoftware zelf bouwen; "alles anders" is zelden een verbetering.
Als tuning niet genoeg is
Het eerlijke verhaal tot slot: een config kan geen hardware toveren. Te weinig RAM voor je spelersaantal, een stapel zware plugins of trage opslag los je niet op met YAML. Wijst spark richting geheugendruk of trage chunk-opslag, dan is een groter pakket simpelweg de betere investering. Bij MC-Node draait elke Minecraft-server op eigen hardware met NVMe-opslag — juist voor chunks een merkbaar verschil — vanaf €0,50 per maand, met ±€1,10 per GB RAM. Alles is maandelijks opzegbaar, dus een maat groter proberen en terugschalen als het overdreven blijkt, kan gewoon.