Direct answer
When lag starts immediately after a configuration change, compare the current config with the last known-good version and revert that one change before attempting unrelated optimization.
How to check it
- Record what file/key changed, the software build, player count and when the slowdown began.
- Inspect startup logs for unrecognized keys, migration warnings or values that were ignored.
- Measure tick time with spark during the affected workload and note whether the cost is entity AI, chunks, redstone, plugin tasks or GC.
- On staging restore the previous value while leaving unrelated settings unchanged.
What to change
- Change one setting group at a time instead of pasting a large config pack.
- Review whether the setting changed gameplay mechanics, spawn behavior, tracking or client packet rate.
- If the option is no longer documented in this software version, remove unsupported overrides rather than guessing replacements.
Software and version notes
Configuration files can be renamed or moved between Paper and forks or across releases. An apparent “optimized” default from a different version may be invalid or behavior-changing.
Practical example: Example: changing hopper checks and mob activation ranges in one copy-pasted config creates two new possible causes. Revert the changes individually and profile a repeatable farm. If the server improves only after restoring a specific setting, document that key and whether its old value depended on a previous Paper release.
Verify the result
- Repeat the same scene and compare before/after MSPT percentiles.
- Check mobs, farms, villagers and client behavior for unwanted side effects.