The phrase 'the server is lagging' can describe several unrelated problems. A client might struggle to render an interior while server scripts remain responsive. A delayed inventory action might involve a slow database query even though frame rate looks normal. Before replacing maps or buying more hosting, identify which symptom you are measuring.
Name the symptom, not the suspected cause
Write down what players see: a low frame rate at one location, delayed interactions, stuttering when new assets stream in, or disconnections during an event. Record whether the symptom affects everyone, one hardware class or a single client. Ask for repeatable steps rather than general descriptions. These observations decide whether to investigate rendering, script execution, network conditions or another subsystem first.
Keep the baseline reproducible
Choose a staging scenario that resembles the real activity. Record the resource versions, game build, relevant settings, client hardware, weather and location. Include a repeatable route and a comparable player or activity load. An empty-server screenshot does not represent a crowded event, and results collected under different graphics settings do not form a fair before-and-after comparison.
- Describe the action and duration of the test.
- Keep the camera route and workload as consistent as possible.
- Note cold-start or fresh-download conditions separately from a warm session.
- Repeat the scenario to identify large variation before drawing conclusions.
Use the right diagnostic tool
The client resource monitor reports resource CPU and memory usage; it is not a complete GPU or streamed-asset benchmark. Use it to identify script activity worth investigating, not to certify that an MLO is free of performance cost. A mostly visual resource can affect rendering without presenting a large script time in the monitor.
Cfx.re documents the resource monitor command as resmon true, with access depending on the client environment and developer mode. The built-in profiler provides a more detailed view of execution over a captured period and can be used on the client or server. Follow the official guide for the current commands and capture workflow rather than copying commands from an unrelated runtime.
Change one thing and repeat
Once you have a plausible hypothesis, make a single controlled change. For a script, that might mean testing a different polling interval or isolating an expensive code path on staging. For a visual symptom, compare the same route with the suspect map disabled, while preserving other conditions. Do not make several changes together and attribute the whole result to the one you hoped would help.
Keep both the original and revised captures. Report the environment, metric, workload and observed variation alongside the result. Avoid universal FPS promises: client hardware, other resources and player activity change the outcome. A small difference inside normal test variation is a reason to measure again, not a performance claim.
Turn a successful experiment into a release check
Recheck startup, player interactions and the original reproduction after applying the change. Watch for a trade-off elsewhere, such as lower script activity accompanied by a noticeable delay in gameplay. Document a rollback step and keep the old configuration until the new one has been observed under representative activity. A useful optimization process is repeatable; it does not depend on a single impressive screenshot.
Read the official profiler guide, resource monitor notes and client console commands. For questions about a particular KAIZO release, include the test context when you contact support.
