Separate network latency from tick performance
A high ping for one player does not prove the server tick loop is overloaded. A typical 20 TPS target provides roughly 50 ms per tick. Check MSPT distributions, player counts, world generation and when spikes occur. Record the server, Java and plugin versions so later results are comparable.
Profile while the problem occurs
Check how spark is provided in your server release. Commands and permissions can vary by version. From the Paper console, inspect help and capture a short profile during the actual issue.
spark profiler --help
spark profiler start --timeout 120In chat, a leading slash is normally required. A shared report may reveal environment and plugin details, so inspect it before making it public. Profiling an empty server does not describe the load during a populated event.
Read the call tree in context
Identify where the main thread spends time. Seeing a plugin name in the tree does not automatically make it responsible for all the cost beneath it. Distinguish code execution, chunk generation, disk activity, garbage collection and waiting. Compare similar time windows at similar player counts.
Change one thing and measure again
For exploration-related load, investigate generation and distance settings. For a specific mechanic or plugin, reproduce the issue on a test copy. Avoid randomly disabling mechanics or protections in production. Compare MSPT and actual gameplay after the change, not just one TPS reading.
- Do not allocate all host memory to the Java heap.
- A longer list of JVM flags is not automatically better.
- Retain the previous configuration and record exactly what changed.
Sources and documentation
Source links are retained for checking dates, availability and original context.