Capture server performance before and after a change

A server can appear faster after a restart simply because fewer players are online or an expensive task has finished. That is why a before-and-after test needs a workload description as well as a resource graph.

Choose one question: did this change improve the problem users actually experienced?

Define a comparable window

Record the player count or request volume, the application version and the activity taking place. Note whether a backup, map render, import or world-generation task was running.

Use a representative interval rather than the quietest minute available. If the problem appears during a specific action, include that action in both tests.

Record more than memory use

Memory is one observation, not a complete explanation. Keep the application's response or tick behaviour, CPU and disk symptoms, and relevant errors alongside it. A change that uses less memory but causes longer pauses is not automatically a better result.

Avoid mixing measurements collected by different tools without explaining what each one means.

Capture the problem while it exists

A profiler report taken after the slowdown ends may not contain the work responsible for it. PaperMC's profiling documentation makes this timing especially relevant to diagnosing a Paper server.

Use the supported profiler for your application and version. Do not paste an old command from an unrelated server implementation merely because it has a familiar name.

Change and compare

Save the original setting, apply one meaningful change and repeat the same test. Record any different workload conditions. If the result is unclear, say so rather than attributing a random improvement to the last setting changed.

When asking for help, include the two observation windows and the change between them. That gives support something testable and helps you decide whether to keep the change or restore the earlier configuration.