Direct answer

Do not change dozens of YAML settings just because a public checklist suggests it. Optimize when a repeatable symptom, hardware limit or profiler report identifies a problem.

Recommended procedure

  1. Record server build, player count, uptime and workload during complaints. Check /spark tps and tick-time distribution rather than only console CPU percentage.
  2. Capture /spark profiler start --timeout 120 during the real lag event, including join rushes, farms or world exploration as relevant.
  3. Classify the cause as ticking, chunk generation, network, memory pressure, disk or a specific plugin before choosing a setting.
  4. Change only one area on staging and document metrics before and after.

What to do next

Keep gameplay requirements, data integrity and recovery time in the same decision as benchmark numbers. Preserving vanilla mechanics may be more important than gaining a marginal MSPT improvement.

How to verify the result

Keep the change only if player complaints, lag spikes or measured capacity improve without regressing gameplay.

Version and compatibility notes

An empty server at 20 TPS is not evidence that a busy server is optimized. Some alternative redstone and AI settings deliberately change game behavior.

Official references

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000