Direct answer

A useful baseline is a reproducible test record, not just one TPS value. Capture server version, CPU/RAM context, settings, player activity and a spark sample before changing performance options.

How to check it

  1. Record the software and Minecraft version, Java version, CPU model/vCPU allocation, RAM/JVM limits, plugins/mods, view distance and simulation distance.
  2. Define repeatable scenarios: quiet server, several players exploring, established mob farms, and a busy realistic peak. Note chunk generation versus pre-generated areas.
  3. For each scenario log player count, duration, FPS/ping reports where relevant, and /spark tps or health output.
  4. During the scenario record /spark profiler start --timeout 300; save the report URL with the timestamp and workload description.
  5. Track not only average MSPT but also worst/long tick spikes, CPU headroom, memory/GC and host disk/network constraints.

What to change

  • Compare only runs with similar players, worlds, plugins, time window and host conditions.
  • Change one optimization at a time, retest each scenario and keep notes about gameplay side effects.
  • Keep at least one untouched profile to distinguish real improvement from a quieter workload or cache warmup.

Software and version notes

TPS of 20 does not prove ample spare performance capacity. Tick time and its distribution are essential. Folia, modded and proxy servers may need different thread/region and client metrics.

Verify the result

  • Store measurements in a simple table with date, configuration revision, workload, TPS, average/percentile MSPT and spark URL.
  • If a change improves idle measurements but damages the peak scenario, treat the change as unproven.
  • Use the same method before/after updates to detect regressions.

References