What an anticheat actually costs your TPS, and how to measure it
Every vendor claims no performance impact. Here is where the time really goes, how to measure it on your own server with your own players, and which work can leave the box entirely.
"No TPS impact" appears on the front page of almost every anticheat. It cannot be true as written. Detection is work, work takes time, and time on a Minecraft server is measured in ticks. The useful question is not whether an anticheat costs you anything, it is where the cost lands and whether that place can absorb it.
Where the time actually goes
Server-side cost falls into a few buckets, and they are not equally dangerous.
Main thread event handling. The expensive one. Every listener that runs on a move, attack or place event is spending your tick budget. Fine at ten players, visible at two hundred, because the cost scales with the number of players multiplied by how often each acts.
World and chunk reads. Movement, scaffold and reach checks all want to know what blocks are near a player. Those lookups are cheap individually and brutal in aggregate, and on a threaded server they are the operations most likely to be illegal from the thread you are on.
Entity scans. Combat checks that search for nearby entities per hit are quietly one of the costliest things an anticheat can do in a crowded fight, which is exactly when you least want it.
The netty threads. Packet-level work happens here rather than on the main thread. This is the bucket most people never think about, and it is the one that scales best, because it is off the tick loop entirely.
The difference between an anticheat that hurts and one that does not is usually which of these buckets it lives in, not how many checks it advertises.
Polled versus packet-driven
A polled design asks a question every tick for every player: where are they now, what changed since last time. The cost is fixed and paid whether or not anything happened.
A packet-driven design does work when a packet arrives, which is when something actually happened. Idle players cost close to nothing. The work also starts on a netty thread rather than the main one, so the tick loop is not waiting on it.
This is why "packet-level" gets repeated so often in anticheat marketing, and also why the phrase has stopped meaning much. Reading packets and then immediately handing everything to the main thread for processing gives you the cost profile of the polled design with extra steps. The question worth asking a vendor is not whether they read packets, but how much of the analysis finishes without touching the main thread.
Measuring it properly on your own server
Vendor benchmarks are run on vendor hardware with vendor players. Yours will differ. The measurement is not hard and takes one evening.
- Profile before you install. Use a sampling profiler and capture a window at genuine peak, not at three in the morning. You want the flame graph and the tick distribution, not just the average.
- Install, and change nothing else. No config tuning, no other plugin updates in the same window. One variable.
- Profile again at a comparable peak. Same day of week, similar player count, similar activity mix. A Friday raid and a Tuesday afternoon are different servers.
- Compare the tail, not the mean. Average TPS hides everything that matters. What you care about is the worst one percent of ticks, because that is what players feel as a stutter mid-fight.
- Look at where the new time is. If the anticheat's frames are on the main thread and grow with player count, you have found a ceiling you will hit later.
If a vendor discourages you from doing this, that is your answer.
What can be moved off the box
Not all detection work has to happen on your server.
The parts that must stay local are the ones needing an immediate decision: cancelling a hit, applying a setback, anything that has to resolve inside the current tick. Those are cheap by nature, because they have to be.
The parts that can leave are the ones needing history rather than immediacy. Trust scoring across a session, correlating behaviour across servers, anything comparing a player now against a population over weeks. None of that has to finish in fifty milliseconds, so none of it has to happen on the machine that is also running your world.
Moving that work off the server changes the shape of the cost. What remains locally is packet inspection and the mitigation decisions, and the analysis that would otherwise dominate your profile happens elsewhere. The trade is a network dependency, which is a real cost and should be weighed honestly: you are adding an outbound connection and a failure mode where that connection degrades. Ask what happens to detection when it does.
How Sheriffguard approaches it
Detection is packet-driven rather than polled, so idle players are close to free and the work starts off the main thread. The heavy analysis, including the trust model and cross-server correlation, runs in our cloud rather than on your box, which is what keeps the local footprint to packet inspection and the mitigation decisions that genuinely have to be immediate.
The honest framing is that this is a trade rather than a free lunch. You are exchanging local CPU for one outbound connection. For most servers that is the right trade, because CPU during a peak fight is the scarcest thing you have. If it is not the right trade for you, that is worth finding out before you buy rather than after.