A calm order of operations for making a server faster.

First, find out which kind of lag you have

Before changing a single setting, decide where the problem lives. The three candidates look identical to a frustrated player and have completely different fixes.

• Ping lag is the network round trip. You feel it as delayed block breaking, hits that do not register, and movement that rubber-bands. It is fixed with a closer region, not with tuning.
• Server lag is a slow tick loop. Everything lags together — mobs, redstone, interactions — and the delay is the same for every player regardless of where they are. This is what the rest of this page addresses.
• Client lag is low frame rate on one machine. It affects a single player, not the world, and is not a server problem at all.

Measure before you change anything

Tuning without a baseline is guesswork, and you will not know whether the change helped or whether the server simply had a quiet moment. Write down two numbers under normal load first: the average tick time and the memory in use.

The game panel is the fastest source for both, and the public status page shows the node behind it. For a deeper reading, the spark profiler records exactly which code is consuming tick time, which is far more useful than any list of generic tweaks, including this one.

Change one thing at a time, then measure again under comparable load. A stack of simultaneous tweaks tells you nothing.

Simulation distance is the biggest single lever

Modern Minecraft separates two settings that used to be one: view-distance in server.properties controls how many chunks are sent to each client, and simulation-distance controls how far from a player the world actually ticks — mob AI, crops, hoppers and redstone.

Dropping simulation distance from a default of ten to six or seven removes an enormous amount of per-tick work across a busy area and is rarely noticed by players, because it changes behaviour far from where they are standing rather than what they can see. Reduce view distance only after that, and only as far as you are comfortable.

Cap entities and tile entities

After distance, the next biggest cost is usually sheer quantity: too many mobs, dropped items, or ticking blocks in loaded chunks.

• Spawn limits. In spigot.yml, the spawn-limits section sets caps for monsters, animals, water creatures and ambient mobs. Lowering these is often the difference between a stable tick and a struggling one.
• Activation range. The entity-activation-range settings decide how close a player must be before a mob starts ticking. Pulling these in stops distant mobs from consuming time nobody can see.
• Dropped items and XP. A farm that leaves thousands of items on the ground will dominate the tick. Fix the collection system, or cap the entity per chunk, rather than periodically deleting everything.
• Tile entities. Hoppers, furnaces and similar ticking blocks are cheap individually and expensive in bulk. A single large storage system can cost more than several players.

Paper configuration files, in plain terms

Paper splits its settings across a few files. It is worth knowing which is which before editing them.

• server.properties holds the world and network basics, including view and simulation distance and the player cap.
• paper-global.yml holds server-wide behaviour such as chunk loading and chunk system settings.
• paper-world-defaults.yml holds per-world tuning: entity activation ranges, mob spawning, despawn distances and similar.
• spigot.yml and bukkit.yml remain from the Spigot heritage and still control spawn limits and some scheduling behaviour.

Do not paste a stranger’s configuration wholesale. These settings interact, and a file tuned for a hundred-player minigame network will make a small survival server feel strange. Change the values that match the problem you measured.

Heap size and garbage collection

Two JVM habits cause most memory-related stutter. The first is leaving the heap to grow on demand, which guarantees pauses as it expands. Setting the minimum and maximum heap equal with -Xms and -Xmx removes that.

The second is over-allocating. More heap is not more speed: a large heap makes each garbage collection longer, and the default collector may not be tuned for a game that needs short, frequent pauses. The widely used Aikar flags pair the G1 collector with a short maximum pause target and a startup-touch option, and they are a sensible starting point for a Minecraft server.

Plugins, farms and storage

Once the world is tuned, look outward. Every plugin adds work to the tick, and a small number of them do something expensive on a timer. If a lag spike arrives on a precise schedule, suspect a scheduled task before suspecting the world.

• Audit plugins you installed and forgot. Two plugins that both modify the same event can together cost far more than either alone.
• Avoid clearing items or unloading chunks on a timer as a first response. It creates a spike and deletes things players or farms depend on.
• Pre-generate your play area with a world border so new terrain is not generated during play. Terrain generation competes directly with the tick loop.
• Keep the world from growing without limit. Trim old regions, and prefer NVMe storage, which every Rynox plan includes, because chunk saving is disk-bound.

Prove the change worked

Return to the numbers you wrote down. If average tick time dropped and memory behaviour is steadier, the change earned its place. If neither moved, revert it and try the next lever. A server that is stable at the right simulation distance beats one that is over-tuned and fragile.

When tuning alone is not enough, the honest answer may be that the plan is undersized for the world. The cost and sizing page explains the tick budget in more detail, and the pricing page lists what each tier includes.

Server performance — questions