The server performance stack: four mods, four bottlenecks

A server-side performance stack is four mods addressing four unrelated bottlenecks. Installing all four is normal; installing one and expecting a general improvement is the mistake almost everyone makes first.

The four bottlenecks

Each has a well-known mod that addresses it, and none of them overlap. That is why the answer to “which performance mod should I install” is “all of them, and also measure first”.

Measuring before installing

Tick time is the number. If the server is taking longer than 50 milliseconds per tick, it is falling behind, and what it is spending that time on tells you which bottleneck you have.

A profiler – the game’s own, or a plugin – gives you a breakdown. Entity ticking, block entity ticking and chunk loading are the three categories that usually dominate.

Large automated farm consuming server resources

What each symptom means

  1. Lag when players explore – chunk generation. Pregenerate.
  2. Lag when everyone gathers – networking or entity count.
  3. Constant lag regardless – game logic, usually farms.
  4. Periodic freezes – garbage collection, meaning memory.
  5. Lag that follows one player – something they built.

The last one is the most common on an established server and the hardest to address socially. A single badly designed farm can consume a third of tick budget.

Farms and tick budget

Automated farms are the largest single source of server load on any server old enough to have them. Item entities, hopper chains, mob spawning and redstone all cost, and they cost continuously.

The fixes are social as much as technical – farm limits, hopper limits per player, and a conversation rather than a config change.

Multiplayer world with many active systems

Memory allocation

More is not better past a point. A server with an enormous heap has longer garbage collection pauses, which players experience as periodic freezes.

The usual guidance is to allocate what the world needs plus headroom, tune the collector, and resist the instinct to allocate everything available.

What actually limits a server is more often single-thread CPU speed than memory, and what actually limits a Minecraft server covers why the hosting comparison charts mislead.

The order to do things in

  1. Measure tick time and profile it.
  2. Pregenerate and set a border.
  3. Install the four optimisation mods.
  4. Tune view and simulation distance.
  5. Address specific farms.
  6. Only then consider hardware.

Steps one to five are free. Step six is the one most people start with, and it fixes the problem roughly a third of the time.

Simulation distance

The most underused lever. Render distance decides what players see; simulation distance decides what is running, and it is far more expensive.

Dropping simulation distance from ten to six while leaving render distance high gives most of the view for a fraction of the cost, and most players never notice.

Plugins versus mods

A hybrid server running both has a third category of load and a third category of conflict. Plugins that touch chunk loading or entity handling interact with optimisation mods in ways neither author tested.

If a server is unexplainably slow and runs both, that interaction is the first place to look.

What none of this fixes

Client-side frame rate. A player complaining about lag may be describing their own machine rather than the server, and the two problems have entirely different fixes.

Establishing which one you are looking at before spending anything is the whole discipline, and the ordering is laid out in what to tune before you pay for more RAM.

Reading a profiler output

Most profiler output points at one chunk or one player, which makes the fix specific rather than general.

Item entities

The quiet killer. A farm producing items faster than hoppers collect them accumulates entities indefinitely, and a few thousand floating items will consume a server.

Checking for large item accumulations is the first thing to do on a server that got slow without any obvious change.

Talking to players about it

Farm limits work better as a conversation than as a config. Most players will redesign a farm happily once they understand why it is a problem; very few respond well to a silent restriction.

The consistent theme across every server performance problem is that the fix is specific and the instinct is general. More RAM, a bigger plan, a faster host – these are general answers to a question that always has a particular one. Half an hour with a profiler beats a month of paying for capacity that was never the constraint.

Images: Embeddium project gallery on Modrinth.