Measure before and after

Record a baseline

Record server/Java/plugin versions, CPU allocation, memory/heap, view/simulation distance, world, active players, and their activity. Distinguish idle players from exploration, moving crowds, and active farms.

Allow warmup, then observe TPS, mean/spike MSPT, GC, post-GC heap, disk latency, and traffic. Idle measurements and interface example numbers are not load-capacity benchmarks.

Profile during the problem

The Paper base provides spark integration. Check /spark help and follow the official Paper profiling guide. A bounded example is:

spark profiler start --timeout 60

In game add / and use the necessary permission. If unavailable, check spark integration for your distribution. Review report contents and access links before sharing.

nusa status details helps inspect module scopes, but overlapping wall times are not CPU percentages. Use a profile to locate costly plugin handlers, entities, chunks, or tasks.

Change one variable

Keep the same world copy, plugins, heap, machine allocation, and activity. Separate startup/warmup/generation from steady-state measurement. Repeat runs and report variation rather than selecting the best one.

When changing culling, ticking, or network cadence, record gameplay differences. Less work because a mechanic stopped is not acceleration of an identical simulation.

Add resources for a measured reason

Single-core speed matters for main ticks. GC can cause pauses, storage can delay load/save, and network fan-out can become congested. Upgrade the resource shown by the bottleneck. If tuning does not help, restore the baseline before the next experiment.