Diagnose the process that is slow
A player’s low FPS, an FXServer hitch warning, slow SQL and connection latency are different problems. First identify who observes the delay, when it occurs and which process records it. A healthy number in one tool does not clear the rest of the system.
Choose a useful first test
| Observation | Start here | Record |
|---|---|---|
| A menu or client script action stutters | Client resmon, then a client profiler capture | Idle versus action CPU/memory and the expensive timeline stack |
| FXServer logs a hitch during gameplay | Server profiler during the action | Warning timestamp, resource revision, affected frame and function |
| Players wait for database-backed actions | Database setup and query timing | SQL operation, duration, errors and corresponding server timeline |
| Loading or rendering stalls with quiet scripts | Asset diagnostics and client diagnostics | Asset changes, location, initial-load versus warm behavior |
| Joining or replication is delayed | Networking and OneSync scope | Exact connection stage, entity ownership and client/server logs |
Record and compare a server hitch
In a private development profile, start with the official profiler commands in the FXServer console:
profiler record 500
profiler statusReproduce the slow action. Once recording completes, save and inspect it:
profiler saveJSON before-hitch.json
profiler viewThe count is frames, not seconds. Follow the complete capture/compare procedure, including viewer access and an equivalent second capture. Capture startup separately from warmed-up gameplay; disk/asset initialization can otherwise dominate a comparison.
Record resource versions, player count, test actions and host conditions alongside the files. Repeat the scenario after one focused change. A single shorter capture is not a validated performance gain, and a generic frame-time or RAM target is not a capacity plan for every server.
Make a change only after evidence
Inspect the costly call stack before changing waits, removing entities or rewriting SQL. Keep frame-dependent drawing responsive, preserve server-side permission checks and compare the result with the same conditions. Use code optimization and load-test planning after finding a bottleneck. Publish measured captures with their limits, rather than universal tuning presets.