Diagnose Anticheat Lag With spark and Tick Timings

Decide whether the anticheat is the cause

Compare tick time and a profiler capture with the anticheat enabled and disabled, under the same player load. If tick time rises only when the anticheat runs, it is a candidate cause. If the profile shows heavy work outside the anticheat, the anticheat is probably not the main problem.

A lag report alone cannot separate the anticheat from entities, chunk loading, other plugins, or network load. Measure before you change the anticheat settings.

Separate TPS, tick time, and ping

These three numbers answer different questions. Mixing them up leads to the wrong fix. TPS is a summary of server speed. Tick time (MSPT) is the time the server spends on each tick, and it shows load more directly. Ping describes the player's connection, which the server cannot fix by tuning checks.

Record a baseline before testing

Capture numbers under a known load before you change anything. A short baseline taken at a random time often misleads, so use the same window and player count for each test.

Keep the baseline in the same notes file as your staging results so you can compare runs later.

• Pick a fixed window, such as one evening peak, and note the player count.
• Record TPS and tick time from your server's status output at regular intervals.
• Record ping for a sample of players on different connection types.
• Note any spikes and the time they happened, then check the console for matching errors.
• Repeat the same window on a second day before you trust the baseline.

Profile the server with spark

spark is a profiler for Minecraft servers. Use it to capture where tick time goes during a spike or a steady load. Run a bounded capture rather than leaving the profiler on. Check the help output of your installed spark version for the exact flags, because command syntax changes between releases.

spark tps
spark profiler --timeout 300
# after the capture finishes, open the report link printed in the console

Read the profile by owner, not by guesses

In the report, look for the largest share of tick time, then identify which plugin owns each busy call path. Compare the anticheat's share with its share in the baseline capture. A large share during a bad moment can also come from a packet flood or from bot traffic, so check the player and packet context around that time before you blame the check code.

Compare with the anticheat disabled

Use the same load script on staging. Run once with the anticheat enabled, then again with its checks disabled or unloaded. Keep everything else the same. If tick time returns to normal only when the anticheat is off, you have a reproducible result to take to the anticheat's maintainers or your admin team.

Do not disable production checks to test. Use staging for this comparison. Repeat each run at least twice, so a single noisy window does not decide the result.

Use a decision table for the next step

Use the observed pattern to choose the next action. Each row is a starting point for investigation, not proof of cause.

What we have not verified

This method does not provide expected tick times, overhead numbers, or product comparisons. Results depend on hardware, Java version, player behavior, and the other plugins on your server. Treat your own staging comparison as the only evidence you can rely on.