If the server waits for a DB response or a file write in the middle of a tick, all game progress on the server stops for that long.
Why The tick waits on DB reads and writes, log writes, or external API calls → Effect If the DB takes 100 ms, the tick stalls for 100 ms too → On screen Every time the DB or disk slows down, the whole field hitches
Hand all slow work (DB reads and writes, log writes, external API calls) off to run asynchronously and apply the results on the next tick (a timeout alone still leaves the tick stalled while it waits).
Ballpark numbers
Even a 0.5 ms DB round trip within the same data center adds up to 50 ms if it’s called 100 times in one tick. That alone uses up the entire 20-tick budget.
On the graph
Random spikes · Server tick time, DB query latency
Where to look
The tick time graph on the same time axis as DB query latency (slow query log and so on) and disk latency. Without tick metrics, bcc offcputime -p to see where the game thread waits
Confirmed if
Tick spikes coincide with DB or file latency spikes, and the game thread’s wait time is concentrated in call stacks that receive DB responses or write files
Ruled out if
DB and disk latency quiet while ticks spike: points to a GC pause or lock contention
ASP.NET Core Best PracticesMicrosoft Call data access, I/O, and long-running work asynchronously; synchronous blocking calls lead to thread pool exhaustion and slow responses