The Best Paper Server Settings for Higher TPS Without Breaking Farms

A Paper server can have plenty of RAM and still run at 14 TPS when 25 players spread out, farms stay loaded, and every hopper starts ticking at once. The best Paper server settings are not a random "anti-lag" preset. They are a set of choices that match your world, player count, plugins, and gameplay rules without quietly breaking redstone or mob farms.

Paper already improves on Vanilla performance, but its defaults are designed to be safe for a broad range of servers. A private SMP with 10 friends can run settings that would feel restrictive on a public survival network. Start with the changes that reduce unnecessary work per tick, then test them under real player load.

Start with your distances

View distance and simulation distance are the biggest performance controls most admins can change without touching advanced config files. They affect two different things.

View distance decides how far chunks are sent to a player. Higher values look better but consume more bandwidth, memory, and CPU during exploration. Simulation distance decides how far chunks actively process game logic, including mobs, redstone, crops, fluids, and many farm mechanics. This is often the setting that decides whether TPS stays stable on a busy SMP.

For most survival servers, start in server.properties with these values:

view-distance=8
simulation-distance=5

Eight chunks of view distance still feels good for normal survival play, especially when players are building, mining, or exploring together. A simulation distance of five preserves a practical local gameplay area while stopping distant chunks from consuming tick time.

If your server is a small, relaxed whitelist world with strong hardware, try view distance 10 and simulation distance 6. If it is a public server where players constantly travel in different directions, 6 to 8 view distance and 4 to 5 simulation distance are usually the safer range. Do not push both to 12 simply because the server starts successfully. The real test is a Saturday night when players are loading new terrain.

Pre-generate the world before opening it

Chunk generation is one of the most expensive jobs in Minecraft. No Paper setting can fully compensate for 20 players flying in opposite directions and generating fresh chunks at the same time.

Pre-generate the Overworld, Nether, and End before launch, especially for public SMPs and content creator communities. Set a reasonable world border, then generate the playable area while the server is otherwise empty. Players will get faster chunk loading, storage activity stays more predictable, and your CPU has more room for mobs and plugins — the full approach is in our guide to reducing chunk loading.

This matters even on fast Ryzen or EPYC hardware with Gen4 NVMe storage. Great hardware shortens the pain, but preventing the workload is better than reacting to it. Once your community grows beyond the initial border, expand and pre-generate again rather than letting launch-day exploration become a TPS stress test.

Tune entity activation, not just mob limits

Entity activation range — a Spigot setting that Paper inherits — determines when nearby entities perform their normal AI and tick behavior. In simple terms, a zombie far from every player does not need to think about pathfinding every game tick.

It lives in spigot.yml, under world-settings → default → entity-activation-range (not in Paper's own config files). A balanced starting point for a survival server is:

world-settings:
  default:
    entity-activation-range:
      animals: 24
      monsters: 32
      raiders: 48
      misc: 16
      water: 16
      villagers: 24

These values reduce background entity work without making the world feel empty. Monsters remain active close to players, while distant mobs stop burning CPU for no useful reason. Villagers deserve special attention: they can be expensive due to AI, workstations, beds, gossip, and pathfinding. Keep their activation range moderate unless your server relies heavily on large trading halls.

Do not set every number extremely low. That can make farms unreliable, freeze entities players expect to behave normally, and create confusing reports such as "my villagers stopped breeding." Paper optimization is about reducing waste, not disabling Minecraft.

For mob density, use the spawn-limits and ticks-per-spawn settings in config/paper-world-defaults.yml carefully. A server built around mob grinders may need higher caps than a casual towny SMP. If players complain that nights feel empty, raise limits in small steps and watch TPS. Changing five performance variables at once makes troubleshooting nearly impossible.

Make hoppers and redstone less expensive

Hoppers are a classic source of invisible lag. One hopper checks inventories repeatedly, which is fine. Hundreds or thousands of them beneath sorting systems, farms, and storage walls are a different story.

In config/paper-world-defaults.yml, use the hopper options to reduce pointless checks:

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

cooldown-when-full is usually an easy win because a full hopper does not need to keep trying to move items every tick. Disabling move events can help considerably, but it has a trade-off: plugins that listen for inventory movement events may depend on them. Check your plugin stack before enabling it, then test common systems such as shops, claims, and custom item sorters. ignore-occluding-blocks makes hoppers skip containers hidden inside solid blocks, which saves checks but can change how a few technical contraptions behave.

Redstone is harder to "optimize" without affecting player builds. Paper's Alternate Current implementation (redstone-implementation) can improve large redstone networks, but it may behave differently from Vanilla in edge cases. Use it only if your community does not depend on technical Minecraft precision, or test it on a copy of the world first. For technical servers, preserving expected behavior is usually worth a little extra CPU time.

Use despawn ranges to clean up forgotten mobs

Players often leave mobs behind: animals from abandoned pens, monsters in caves, dropped items after PvP, and boats or minecarts near old bases. These entities add up over weeks.

Paper lets you configure despawn ranges by mob category. Keep soft despawn ranges moderate so entities far from players disappear naturally, while hard despawn ranges prevent massive hidden piles from staying loaded forever. Be cautious with animals and villagers. Aggressive despawning can hurt legitimate farms and make players feel like the server is deleting their work.

For dropped items, adjust the merge radius in spigot.yml instead of allowing hundreds of individual item entities to sit on the ground. A reasonable merge radius reduces entity count around farms and mob grinders while still letting players collect loot normally. Test this with custom items and plugins that attach data to dropped items.

Control the plugins that actually hurt TPS

A bad plugin can erase every gain from the best Paper configuration. Common troublemakers include outdated anti-cheat tools, poorly configured map renderers, excessive scoreboard updates, chat formatting that runs heavy database queries, and plugins that scan every loaded chunk on a schedule.

When TPS drops, profile before changing settings blindly. Check whether the main thread is spending time on entities, chunk loading, redstone, scheduled tasks, or one specific plugin. A plugin that performs a small task for every online player every tick becomes expensive fast — see how to install Paper plugins without breaking TPS and our list of anti-lag plugins worth using.

Keep your Paper build and plugins current, but update with a rollback plan. Back up the world and plugin data before larger updates, then test new versions outside peak hours. Automatic backups are not glamorous until an incompatible update corrupts a world or resets player inventories.

JVM and hardware still matter

Paper settings cannot fix slow single-core CPU performance. Minecraft's main tick loop leans heavily on one fast core, which is why high-frequency Ryzen and EPYC infrastructure matters more than a huge core count on weak hardware.

Give the server enough RAM for its world, plugins, and player count, but avoid treating RAM as the only performance metric. More memory will not solve a main-thread bottleneck. For a small Paper SMP, 4 GB may be enough; a plugin-heavy community server or a large pre-generated world may need 8 GB or more. Watch actual usage before upgrading — our breakdown of how much RAM a Paper server needs has the numbers.

Use modern JVM flags appropriate for your Java version, and avoid copying ancient startup strings from forum posts. If your hosting panel provides a tested Paper preset, use that as your baseline. On managed Minecraft hosting such as Elysium, the useful work is keeping the server configuration, backups, storage, and CPU allocation dependable so you can focus on what players actually notice: stable TPS and a world that is still there tomorrow.

Test changes like an admin, not a guessing game

Change one category at a time, restart when required, and test with realistic activity. Have players explore, run farms, trade with villagers, use portals, and visit the busiest base. A server that reports 20 TPS with nobody online has not passed a performance test.

Keep a copy of each working configuration before major tuning. If a setting improves TPS but breaks a key farm or plugin, revert it and choose the smaller gain. Your best setup is the one that stays smooth while preserving the kind of Minecraft your community came to play. If you need even more knobs, Purpur builds on Paper with extra gameplay and performance options.