Minecraft server performance tuning that actually helps

A Minecraft server has 50 milliseconds to finish everything it needs to do in a tick. If it finishes early, it waits. If it finishes late, you get "Can't keep up!" in the console and rubber-banding for your players. Almost all performance work comes down to finding what is eating that budget.

The frustrating part is that most of the advice circulating in Discord servers is folklore. Adding more RAM to a server that is CPU bound does nothing. Copying someone else's JVM flags does very little. Here is the order that actually pays off.

1. Measure before you change anything

Install Spark. It is the single most useful thing you can do, and it turns guessing into reading. Run a profile while the server is struggling, not while it is idle, and look at what is on top of the tick.

/spark profiler start --timeout 120
/spark tps
/spark healthreport

Nine times out of ten the answer is immediately obvious: one plugin doing something expensive on every tick, a hopper array, an entity pile-up in a chunk nobody has visited in weeks, or a world generation storm from a player flying at speed.

2. Fix entities before you touch config files

Entity count is the most common cause of a server that used to be fine and now is not. Mob farms, item accumulation, and stacked animals from a breeding project all add per-tick work that never goes away on its own.

• Find dense chunks with Spark or a plugin that reports entity counts per chunk.
• Cap animals per chunk in your server configuration rather than asking players nicely.
• Set a sane item despawn rate — dropped items are cheap individually and expensive in the thousands.
• Look hard at any farm that produces items faster than players collect them.

3. Tune your view and simulation distance

This is the highest-leverage setting on the server and the one people are most reluctant to touch. Simulation distance controls how far out the server actually ticks the world; view distance controls how much it sends to clients. They do not need to match.

Dropping simulation distance from 10 to 6 while leaving view distance at 8 or 10 usually costs players very little visually and returns a large amount of tick budget. Try it before you buy a bigger plan.

4. Audit your plugins honestly

Plugin count matters less than plugin behaviour. One badly written plugin scanning every online player's inventory every tick will outweigh thirty well-behaved ones. Spark will name the offender; the hard part is being willing to remove a plugin your players like.

If a plugin is essential and slow, check whether a maintained alternative exists. A lot of popular plugins have modern rewrites that do the same job without the per-tick cost.

5. Use Paper's configuration properly

If you are on Paper or Purpur, the per-world configuration files expose genuinely useful controls: mob spawn ranges, redstone implementation, hopper transfer rates, chunk loading limits and entity activation ranges. These are the settings the platform authors added specifically for the problems you are having.

Read what each option does rather than pasting a config from a YouTube description. Some of them change gameplay, and finding out from your players is worse than finding out from documentation.

6. Only then consider hardware

If Spark says you are CPU bound on the main thread and your configuration is already sensible, then you have a genuine hardware ceiling and a higher clock speed will help. If Spark says you are spending your time in garbage collection and your memory is nearly full, more memory will help.

Those are two different problems with two different answers, which is exactly why measuring first matters. Buying a bigger plan to solve a plugin problem just means you pay more for the same lag.

A reasonable order of operations

1. Install Spark and profile during a bad moment.
2. Deal with whatever is at the top of the profile.
3. Bring entity counts under control.
4. Lower simulation distance and see if anyone notices.
5. Remove or replace the slowest plugin.
6. Tune per-world Paper settings deliberately.
7. Scale memory or move to faster cores based on what you measured.