Minecraft Server Optimization: How to Maintain 20 TPS with 50+ Players

Running a Minecraft server with 50 or more concurrent players is a different discipline from hosting a casual server for a handful of friends. At that scale, every misconfigured option compounds into visible lag, and a single poorly written plugin can tank your TPS during peak hours. This guide covers the full optimization stack: server software, configuration files, JVM tuning, plugin auditing, world preparation, and hardware sizing. Every recommendation here is grounded in production experience and backed by the settings that experienced server administrators actually run.

Why TPS Is the Only Metric That Matters

Minecraft runs on a fixed-rate game loop. The server attempts to process one tick every 50 milliseconds, which produces 20 ticks per second (20 TPS). Within each tick, the server must:

Advance the AI state machine for every loaded mob
Process every active redstone circuit
Move every entity (players, projectiles, falling blocks, item frames)
Grow crops, spread fire, and advance block states
Respond to every player action queued since the last tick
Send chunk and entity updates to all connected clients

If all of that work takes longer than 50 ms, the tick overruns. The server finishes the tick before starting the next one on schedule, causing the game loop to slow down. TPS falls below 20.

The consequences are cascading. A server running at 15 TPS is effectively running in slow motion: crop growth slows, mob pathfinding stutters, and player interactions (breaking blocks, opening inventories, trading with villagers) feel delayed. Below 10 TPS, the experience becomes genuinely unplayable for most players.

Ping (network latency) is a separate concern. A server at perfect 20 TPS still feels laggy to a player with 300 ms ping. But no amount of low latency compensates for a server at 12 TPS. Fix TPS first.

Understanding the Tick Loop in Detail

Each tick passes through several processing phases. Knowing what happens lets you identify where budget is being wasted.

Phase 1: Player input processing. The server reads all packets that arrived from clients since the last tick. Movement, block interactions, inventory clicks, and chat messages are queued here.

Phase 2: Entity ticking. This is usually the heaviest phase on large servers. Every loaded entity executes its AI goal selector, pathfinds, and updates its position. With default settings and uncontrolled mob spawning, this phase can exceed 20 ms on its own.

Phase 3: Block entity ticking. Tile entities such as hoppers, furnaces, brewing stands, and pistons fire here. Hoppers are notorious for burning tick budget, processing item transfers every tick even when idle.

Phase 4: Chunk ticking. Active chunks process random block updates (crop growth, leaf decay, grass spread, ice formation). The number of chunks ticking is a direct function of your simulation distance setting.

Phase 5: Scheduled tasks and plugin hooks. Plugins that registered repeating tasks or event listeners run in this phase. A poorly written plugin iterating over all online players every tick is a common culprit on large servers.

Phase 6: Network flush. The server serializes and sends outbound packets to all clients.

Use the Spark profiler (covered later) to see the exact millisecond cost of each phase on your specific server.

Server Software: Paper or Purpur for High Player Counts

Vanilla and CraftBukkit are not viable options for 50+ player servers. Spigot is acceptable but exposes fewer tuning knobs than its successors.

Paper is the standard choice for production servers that need stability and broad plugin compatibility. Paper applies hundreds of patches on top of Spigot, including async chunk loading, entity activation range controls, and mob spawn throttling. Its configuration files (paper-world-defaults.yml, paper-global.yml) expose granular controls that do not exist in vanilla or Spigot.

Purpur is a fork of Paper that adds additional gameplay configurability (per-mob behavior toggles, rideable mobs, configurable block behaviors) without sacrificing Paper’s performance patches. Purpur is a solid choice if you want more gameplay flexibility on top of Paper’s optimization baseline. All Paper configs apply unchanged under Purpur.

Folia is an experimental Paper fork that shards the world into independently ticking regions to take advantage of multiple CPU cores. It breaks a large number of plugins and requires rewrites of most non-trivial plugin logic. Folia is not recommended for production servers running third-party plugins unless your development team has explicitly tested compatibility.

For most high-population servers, Paper is the safe, well-supported default. Download it from papermc.io.

paper-world-defaults.yml: The Most Important Config File

This file controls per-world behavior. Changes here apply to all worlds unless overridden in per-world config files. The following are the settings with the highest impact on large servers.

Entity Activation Range

Entity activation controls which entities run full AI and which run a reduced “inactive” tick. Entities outside a player’s activation range still exist but stop pathfinding and doing expensive AI calculations.

entities:
  activation-range:
    animals: 32
    monsters: 32
    raiders: 48
    misc: 16
    water: 16
    villagers: 32
    flying-monsters: 48
  tick-rates:
    sensor:
      villager:
        secondarypoisensor: 40
        nearestbedsensor: 80
        villagerbabiessensor: 40
        playersensor: 20
        nearestlivingentitysensor: 40
    behavior:
      villager:
        validatenearbypoi: 60
        acquirepoi: 120

Setting animals and monsters to 32 blocks means entities further than 32 blocks from any player stop running expensive AI. This alone can reduce entity tick time by 40 to 60 percent on servers with high mob populations.

Villager sensors are expensive. The values above (secondarypoisensor: 40, nearestbedsensor: 80) reduce how frequently villagers scan their surroundings. The visible effect is a slight delay in villager pathfinding responses, which is imperceptible to most players.

Mob Spawn Limits

spawn-limits:
  monsters: 20
  animals: 5
  water-animals: 2
  water-ambient: 2
  water-underground-creature: 3
  axolotls: 3
  ambient: 1

These values are per-player multipliers in Paper (unlike vanilla where they are absolute world caps). With 50 players online, monsters: 20 allows up to 1000 hostile mobs across all loaded chunks. Reducing these to the values above significantly cuts entity tick overhead while keeping the gameplay experience intact.

View Distance vs. Simulation Distance

These are two distinct settings and they must be configured independently for best results.

view-distance: 8
simulation-distance: 4

View distance controls how many chunks around a player are sent to the client for rendering. Players can see chunks at view-distance 8 (128 blocks), but those distant chunks do not process game logic.

Simulation distance controls how many chunks actually tick. Keeping simulation distance at 4 (64 blocks) dramatically reduces the number of active chunk ticks, which cuts random block updates, crop growth calculations, and fire spread processing.

This combination (view 8, simulation 4) is the most common production setting for high-population servers. Players see a wide world but only the chunks close to them actually simulate.

Chunk Loading Settings

chunk-loading:
  min-load-radius: 2
  max-concurrent-sends: 2
  auto-config-send-distance: true
  target-player-chunk-send-rate: 100.0
  global-max-chunk-send-rate: -1.0
  enable-frustum-priority: false
  global-max-chunk-load-rate: -1.0
  player-max-concurrent-loads: 20.0
  global-max-concurrent-loads: 500.0

target-player-chunk-send-rate: 100.0 caps how many chunk packets are sent to an individual player per second. On join, a player can otherwise request hundreds of chunks simultaneously, spiking network and CPU usage for all other players on the server.

max-concurrent-sends: 2 limits simultaneous chunk sends per player, smoothing out the join spike further.

paper-global.yml: Server-Wide Settings

chunk-system:
  worker-threads: -1  # auto-detect, uses (cpu_count / 2) threads
  io-threads: -1

async-chunks:
  threads: -1

packet-limiter:
  all-packets:
    action: DROP
    max-packet-rate: 500.0
  overrides:
    ServerboundPlaceRecipePacket:
      action: DROP
      max-packet-rate: 20.0

velocity-support:
  enabled: false  # set true if using Velocity proxy
  online-mode: true
  secret: ''

timings:
  enabled: false  # disable in production; use Spark instead

item-validation:
  display-name: 8192
  loc-name: 8192
  lore-line: 8192
  book:
    title: 8192
    author: 8192
    page: 16384

Disabling timings in production is important. Timings collects detailed per-tick telemetry that is useful for diagnostics but imposes a measurable overhead. Use Spark for profiling (it has a lower overhead profiler) and keep timings off during normal operation.

The packet limiter protects against clients sending malformed or excessive packets. max-packet-rate: 500.0 per second is generous enough for legitimate play while blocking packet flood attacks.

spigot.yml Optimizations

world-settings:
  default:
    mob-spawn-range: 6
    entity-tracking-range:
      players: 48
      animals: 48
      monsters: 48
      misc: 32
      display: 128
      other: 64
      experience_merging_range: 3.0
    entity-activation-range:
      animals: 32
      monsters: 32
      raiders: 48
      misc: 16
      water: 16
      villagers: 32
      flying-monsters: 48
      wake-up-inactive:
        animals-max-per-tick: 4
        animals-every: 1200
        animals-for: 100
        monsters-max-per-tick: 8
        monsters-every: 400
        monsters-for: 100
        villagers-max-per-tick: 4
        villagers-every: 600
        villagers-for: 100
        flying-monsters-max-per-tick: 8
        flying-monsters-every: 200
        flying-monsters-for: 50
    ticks-per:
      animal-spawns: 400
      monster-spawns: 1
      water-spawns: 1
      water-ambient-spawns: 1
      water-underground-creature-spawns: 1
      axolotl-spawns: 1
      ambient-spawns: 1
      autosave: 6000
    nerf-spawner-mobs: false
    arrow-despawn-rate: 1200
    trident-despawn-rate: 1200
    merge-radius:
      item: 3.5
      exp: 4.0
    max-entity-collisions: 2
    save-structure-info: true

Key values here:

entity-tracking-range defines how far players receive entity position updates for each entity type. Reducing these from vanilla defaults (where monsters track at 96+ blocks) reduces packet volume significantly. Monsters at 48 blocks means players only receive mob movement packets when mobs are within 48 blocks, which is close enough to matter for combat.

merge-radius for items (3.5) and experience orbs (4.0) reduces entity count by merging nearby drops and XP orbs into single entities. This is one of the most effective passive optimizations for survival servers.

max-entity-collisions: 2 caps how many collision checks an entity performs per tick. Without this cap, stacked mobs (common in mob farms) can produce O(n²) collision calculations.

ticks-per.animal-spawns: 400 means the server only attempts to spawn passive animals every 400 ticks (20 seconds) instead of every tick. Animals are low priority for gameplay; this reduces spawning overhead significantly.

bukkit.yml Tuning

spawn-limits:
  monsters: 70
  animals: 10
  water-animals: 5
  water-ambient: 20
  water-underground-creature: 5
  axolotls: 3
  ambient: 15

chunk-gc:
  period-in-ticks: 600

ticks-per:
  animal-spawns: 400
  monster-spawns: 1
  water-spawns: 1
  water-ambient-spawns: 1
  water-underground-creature-spawns: 1
  axolotl-spawns: 1
  ambient-spawns: 1
  autosave: 6000

The spawn-limits here are the absolute world caps before Paper’s per-player scaling applies. Set them conservatively and let Paper’s per-player logic handle the scaling.

chunk-gc.period-in-ticks: 600 runs chunk garbage collection every 30 seconds. This controls how quickly unloaded chunks are evicted from memory. On servers with high player movement, more frequent collection prevents memory bloat.

autosave: 6000 saves the world every 5 minutes. More frequent autosaves protect against data loss but increase I/O load. For servers on SSDs or NVMe drives, 6000 ticks is a reasonable interval.

JVM Startup Flags: Aikar’s Flags by Memory Tier

The Java virtual machine has a significant impact on server performance. Garbage collection pauses directly cause TPS spikes. Aikar’s flags tune the G1 garbage collector for Minecraft’s allocation patterns (many short-lived objects with occasional large allocations).

8 GB RAM (Minimum for 50 Players)

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true \
  -jar paper.jar --nogui

16 GB RAM (Recommended for 50+ Players)

java -Xms14G -Xmx14G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=40 \
  -XX:G1MaxNewSizePercent=50 \
  -XX:G1HeapRegionSize=16M \
  -XX:G1ReservePercent=15 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=20 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true \
  -jar paper.jar --nogui

Critical notes on memory sizing:

Set -Xms equal to -Xmx. This forces the JVM to pre-allocate all heap memory at startup, eliminating the overhead of requesting additional memory from the OS during play.
Leave 1 to 2 GB of system RAM free for the OS, off-heap JVM memory, and Paper’s async I/O threads. Do not allocate 100% of system RAM to the heap.
G1HeapRegionSize should scale with heap size. Use 8M for heaps under 12 GB and 16M for heaps at 12 GB or above.
InitiatingHeapOccupancyPercent: 20 triggers GC cycles earlier, preventing long stop-the-world pauses caused by a nearly full heap.
AlwaysPreTouch touches all heap pages at startup, preventing page faults during play that would cause brief but measurable TPS drops.

Plugin Audit: Finding Lag with Spark

Installing Spark is non-negotiable for serious server administration. Spark is a sampling profiler that measures the actual CPU cost of every method call in the server process with minimal overhead.

Install Spark from spark.lucko.me and drop the jar in your plugins folder.

Basic Profiling Workflow

/spark profiler start
# Let the server run under normal player load for 5-10 minutes
/spark profiler stop

Spark generates a report URL. Open it in your browser and examine the flame graph. Look for:

Methods consuming more than 5% of tick time. These are your primary targets.
Plugin method calls in the entity tick or scheduler branches. A plugin’s onTick or repeating task showing up high in the flame graph is a red flag.
hopper.tick consuming disproportionate time. This indicates excessive hopper activity that needs addressing through item filter plugins or hopper clock reduction.

Common Plugin Lag Sources

Symptom in Spark	Likely Cause	Fix
`clearlag.EntityTask` high CPU	ClearLag running too frequently	Increase interval or replace with Paper’s built-in entity limits
`essentials.spawn` delays on join	EssentialX spawn calculation	Cache spawn positions, reduce spawn radius scan
`worldguard.query` in every event	WorldGuard region lookups on frequent events	Use spatial indexing, avoid querying on high-frequency events
`plugin.scheduler` > 10%	Plugin running tasks every tick	Profile the specific plugin; report to its developer
`chunk.load` spikes every 30s	Autosave interval too low	Increase to 6000 ticks

Remove or replace any plugin that cannot justify its tick budget. A plugin that saves 30 minutes of admin time per week is not worth 3 ms per tick (which costs you 6% of your tick budget on a 50 ms deadline).

World Pre-Generation with Chunky

Chunk generation is one of the most CPU-intensive operations a Minecraft server performs. When a player walks into an ungenerated area, the server must generate terrain, apply biome decoration, structure placement, and ore distribution, all within the same tick loop that is also handling 50 players.

Pre-generating your world border before opening the server eliminates this spike entirely.

Install and Configure Chunky

Download Chunky from github.com/pop4959/Chunky and place it in your plugins folder.

# Set your world border first (in-game or via worldborder command)
/worldborder set 10000  # 10,000 block radius = 20,000 x 20,000 world

# Start pre-generation for the overworld
/chunky world world
/chunky center 0 0
/chunky radius 5500
/chunky start

# Repeat for nether and end
/chunky world world_nether
/chunky radius 2000
/chunky start

For a 10,000 block radius overworld, expect generation to take 2 to 8 hours depending on your CPU, with Paper’s async chunk system doing most of the work in background threads without impacting TPS.

Set a hard world border to prevent players from generating new terrain during play:

/worldborder set 10000
/worldborder damage amount 1.0
/worldborder damage buffer 5

Entity Management Strategies

Mob Cap Configuration

The most effective mob cap strategy for 50+ player servers is to reduce the global mob caps and rely on per-player activation range (configured above) to ensure players still encounter mobs near them.

Beyond configuration, enforce server rules against automated mob farms that accumulate entities. A single iron golem farm with 100 villagers contributes more to entity tick overhead than 500 naturally spawned zombies scattered across the world.

Hopper Optimization

Hoppers check for items to transfer every tick by default. On survival servers with complex farms, hopper lag compounds quickly.

Configure Paper’s hopper settings in paper-world-defaults.yml:

hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-blocks: true

cooldown-when-full: true stops the hopper from re-checking for items when its output container is full. This is the single most effective hopper optimization and has zero gameplay impact.

For servers with extreme hopper counts, the plugin BottledExp or Item Optimizer can reduce entity processing further, but Paper’s built-in cooldown covers most cases.

Redstone Limits

Vanilla redstone, particularly complex clocks and large piston arrays, can consume significant tick budget. Paper does not limit redstone by default, but you can restrict it in two ways:

Use the redstone-implementation: EIGENCRAFT or redstone-implementation: ALTERNATE_CURRENT option in paper-world-defaults.yml. Alternate Current is a community-developed redstone algorithm that is significantly faster for large circuits.

redstone-implementation: ALTERNATE_CURRENT

Set world rules to limit clock rates:

/gamerule maxCommandChainLength 65536

For servers where redstone abuse is a concern, consider plugins like RedstoneLimit that cap how many activations a single circuit can perform per second.

Hardware Requirements for 50+ Player Servers

Minecraft server performance is primarily single-threaded. The main game loop runs on one core. Having 32 cores does not help if each individual core is slow.

Minimum Specification for 50 Players

Component	Minimum	Recommended
CPU	3.5 GHz single-thread, 4 cores	4.0+ GHz, 6+ cores
RAM	8 GB	16 GB
Storage	SSD (SATA)	NVMe SSD
Network	100 Mbps	1 Gbps
OS	Ubuntu 22.04 LTS	Ubuntu 22.04 LTS

Single-thread clock speed is the dominant factor. A server with a 4.5 GHz processor and 4 cores will outperform a server with a 3.0 GHz processor and 16 cores for Minecraft specifically.

The async improvements in Paper (chunk loading, I/O) do benefit from additional cores, but the main game loop remains single-threaded. Budget for CPU clock speed first.

NVMe storage matters on join spikes. When 10 players log in simultaneously, the server fetches player data and loads chunks. On an NVMe drive this completes in under 100 ms. On a spinning hard disk it can take several seconds, during which the main thread stalls.

CraftRift’s infrastructure runs dedicated CPU cores (not shared vCPUs) from its Singapore data center, which eliminates the “noisy neighbor” problem where other customers on the same physical machine steal CPU time from your server during their peak hours. This is particularly important for game servers where consistent single-thread performance matters more than aggregate throughput.

Monitoring and Benchmarking

/tps and /mspt

Paper exposes two built-in commands for basic performance monitoring:

/tps

Reports the 1-minute, 5-minute, and 15-minute TPS averages. This is the first command to run when investigating a lag report. 20.0 across all three averages indicates a healthy server.

/mspt

Reports milliseconds per tick averages. This is more granular than TPS. At 20 TPS, each tick has a 50 ms budget. An /mspt reading of 35 means the server is consuming 35 of its 50 ms budget per tick, leaving 15 ms headroom. A reading above 45 ms means TPS drops are imminent under any additional load.

Continuous Monitoring with Spark

Beyond on-demand profiling, Spark provides a health command:

/spark healthreport

This reports CPU usage, tick duration, GC pressure, and memory allocation rate in a single summary. Run it during peak hours to establish a baseline, then compare after making config changes.

What Numbers to Target

Metric	Healthy	Warning	Critical
TPS (1 min avg)	19.5 to 20.0	17.0 to 19.5	Below 17.0
MSPT (avg)	Under 30 ms	30 to 45 ms	Above 45 ms
GC pause frequency	Under 1 per minute	1 to 3 per minute	Above 3 per minute
Heap usage	Under 60%	60 to 80%	Above 80%
Entity count	Under 2000 per world	2000 to 5000	Above 5000

Set up alerts through your server panel or a monitoring tool (Prometheus with the Spark metrics exporter, or Grafana) to notify you when TPS drops below 18 for more than 60 seconds. Catching degradation early, before players notice and complain, is the mark of a well-run server.

Frequently Asked Questions

Q: My TPS is fine during the day but drops at night. What causes this?

Nighttime mob spawning combined with players sleeping through the night in multiplayer (or not sleeping, leaving mobs active all night) causes entity counts to spike. Check /spark profiler during the nighttime hours and look at entity tick cost. If that is the culprit, reduce spawn-limits.monsters in paper-world-defaults.yml or increase the simulation distance reduction to limit active chunks.

Q: A specific player seems to cause TPS drops when they log in. Why?

This is almost always one of three things: (1) the player has a complex contraption in their base that was unloaded and is now reloading with a burst of block updates and entity spawns; (2) the player’s base has an excessive number of item entities on the ground; (3) the chunk load request on join is hitting ungenerated territory. Pre-generate your world and use the Spark profiler with /spark profiler --only-ticks-over 50 to catch the exact tick where the lag occurs during their login.

Q: Should I use async plugins for chunk generation and entity processing?

Paper already handles chunk I/O asynchronously. Third-party async plugins that claim to make entity ticking async are almost always either unsafe (risking data corruption) or simply shifting work to a different thread that still competes for the same resources. Stick to Paper’s built-in async systems and focus on reducing the total amount of work rather than parallelizing it.

Q: My server has 16 GB RAM and I am still getting GC pauses. What is wrong?

Check your JVM flags. If you launched the server without Aikar’s flags, the JVM uses its default GC settings which are tuned for throughput, not low latency. Switch to the Aikar flags in the section above. Also verify that -Xms equals -Xmx. If Xms is lower than Xmx, the heap resizes during play, which triggers GC cycles.

Q: Is there a safe plugin count limit for a 50-player server?

Plugin count is not the meaningful metric. One badly written plugin can do more damage than 50 well-written ones. The meaningful metric is total tick budget consumed by plugin code. Use Spark to measure it. If plugin code collectively consumes less than 5 ms per tick, you have headroom. If a single plugin consistently consumes more than 2 ms per tick with no clear justification, investigate or replace it.

Q: Do I need a proxy like Velocity or BungeeCord at 50 players?

Not necessarily. A single well-configured Paper server on adequate hardware handles 50 to 100 players without a proxy. Proxies are warranted when you need multiple server instances (lobby, survival, minigames) under one IP. For a single-server community, adding a proxy introduces a network hop and increases operational complexity without benefiting TPS.

Q: What is the maximum player count achievable on Paper with these settings?

With the configurations in this guide, adequate hardware (16 GB RAM, dedicated 4.0+ GHz cores), pre-generated world, and a disciplined plugin stack, 80 to 150 concurrent players on a single Paper instance is achievable. Servers like CraftRift that provide dedicated CPU cores rather than shared vCPUs allow you to reach the upper end of that range consistently, since your tick budget is not competing with other customers on the same physical host.

Maintaining 20 TPS with a large player base is not a one-time configuration task. It is an ongoing discipline. Profile regularly, audit plugins before installing them, pre-generate before launching new worlds, and monitor the metrics in the table above. The configuration values in this guide represent a proven starting point. Every server is different, and the exact numbers you land on will depend on your specific plugin stack, world characteristics, and player behavior. Use Spark to validate every change you make against actual tick data, not just intuition.