Skip to guide

Documentation 9.6.24

Settings and performance

Measure on your own server. Player count, resources, evidence capture and database indexes all affect load; no zero-lag guarantee is made.

Start with observation#

Review detection logs against normal gameplay before choosing kick or ban actions. Test teleports, respawns and legitimate weapon grants. Client signals are evidence to validate, not authority to grant money, weapons or administrator rights.

Keep expensive work deliberate#

Leave deep scans and automatic quarantine disabled unless you are testing them. Limit simultaneous live captures. The new bridge does no idle game-database reads; its HTTPS health poll and the other anti-cheat modules still use resources. Use the FiveM profiler before and after configuration changes.

Measure a repeatable baseline#

Take a server profile during a representative session before changing settings. Note the player count, artifact, resource versions and activity: quiet roleplay, crowded garages and combat can produce very different work. Compare the same kind of session after one change. Server CPU time, hitch warnings and query behavior are more useful than a promise of a fixed FPS gain.

The commands below record a bounded sample and show its status. Wait for recording to finish before opening the profile. Inspect the resource and thread responsible for a spike instead of assuming every hitch comes from the anti-cheat. Save a private before/after note with the exact changed setting. A short recording cannot predict every peak-hour workload.

profiler record 500
profiler status
profiler view

tosunac_doctor

Choose cost controls without removing safeguards#

Leave optional deep scans and automatic quarantine off until you have a controlled reason to test them. Limit concurrent live evidence captures and avoid keeping debug output enabled in production. Do not shrink polling or detection intervals simply to make the panel feel immediate: a shorter interval increases repeated work.

  1. Test idle operation and one ordinary panel read separately. The database bridge does no idle game SQL reads, but its HTTPS health traffic and other AC modules still consume resources.
  2. Check large player and vehicle lists by paging. Inspect database indexes through the maintainer when a supported read is refused.
  3. Measure one capture with a test account before asking several staff members to watch simultaneously.
  4. If cost rises after a change, restore that setting and repeat the same workload before changing unrelated modules.

Tune punishment from context and evidence#

Keep context-sensitive checks at their suitable observation settings until ordinary gameplay has been tested. A log entry is a signal to investigate, not an instruction to ban every matching player. Verify character selection, revive, teleports, police equipment and scripted weapons. Add a specific server integration rather than a broad permanent exemption.

The config doctor runs after settings are applied and can be run with tosunac_doctor. It reports risky effective values but never changes them. Review warnings about aggressive punishment, disabled safeguards, debug and fail-open behavior. Panel values may override a local default; diagnose the effective configuration, not only the file on disk.

An exemption or relaxed action can reduce visible complaints without solving the actual cause. Keep a dated list of temporary exceptions and the scripts that need repair. Remove an exception after the integration is verified, then repeat the accepted gameplay scenario and compare its logs with the earlier run.

  • Change one setting and record why, who reviewed it and the previous value.
  • Compare repeated detections with legitimate script actions and timestamps.
  • Retest relevant gameplay after increasing a punishment or changing a framework/inventory resource.
  • Restore the previous value if a new false positive appears, then fix the cause before tightening again.

Compare the same workload before and after a change#

For each test session, record player count, artifact version, AC package, framework and inventory versions, and any active panel operations. Measure a quiet session without panel requests first, then representative character selection, garage use and ordinary combat. Use profiler record 500 for a bounded sample and wait for profiler status to show completion before assessing it.

In profiler view, identify the resource and thread responsible for a CPU spike. Consider repeated long executions and matching hitch warnings as well as averages. Change one setting and repeat the scenario at a similar player load. Capture another representative session for problems that only appear at busy times. Changing several settings together makes it impossible to attribute the result reliably.

Measure database bridge work independently#

The bridge can maintain health communication, but idle panel polling does not continuously read player lists from the game database. The implementation keeps one outbound request in flight. Its normal health interval is approximately ten seconds, with failed connections backing off to at most two minutes. These describe current behavior, not a user-adjustable speed control or a guaranteed panel refresh deadline.

Use tosunac_db_status in the server console to inspect the local state. Compare one page of player results against the idle sample. Bridge lists use pages of 25 records and bounded response sizes rather than transporting the entire database. If unsupported_index or schema_unavailable appears, inspect the supported schema and indexes with an authorized database administrator instead of forcing wider queries.

Write acceptance criteria and a rollback note#

Before maintenance, define acceptance criteria suitable for your server: no new sustained hitch warnings, normal gameplay completing and any significant duration increase explained. Avoid a universal FPS target because player hardware, other resources and database conditions vary. A faster profile also does not make false detections acceptable.

Record the old and new values, test time, player count and observed effect. If load increases, restore the single changed value and repeat the scenario. Do not edit balances simply to measure performance. Give support a sanitized profile summary and configuration doctor warnings. Observe a representative normal session after returning to production to ensure that temporary test conditions did not conceal the real workload.

Distinguish a single spike from recurring work#

Do not change settings solely because one profile row has the highest duration. Inspect which resource and thread repeatedly runs and which action matches it. One-time preparation during joining differs from work repeated every tick. If a spike appears only on the first garage opening, compare the second and third openings; repeated increases suggest a shared workflow. If another resource changed during the test, the difference cannot be attributed only to AC. A short recording also does not represent every busy-hour condition.

Record duration, frequency and action together. A resource may accumulate time through short regular work while a single long operation aligns with a hitch. Server profiler time is not a player client FPS reading. Compare a client stall with the same server interval; latency and loaded assets may require separate investigation. Request help with a relevant sanitized profile excerpt and scenario rather than shortening every detection interval when interpretation is uncertain.

Measure the observation tools themselves#

Live monitoring and diagnosis also create work. Combining a long profiler recording, many panel reads, evidence images and continuous debug output makes attribution difficult. Keep tools limited first, then compare a sample with one tool enabled. Refreshing the same page in several tabs does not improve measurement of one player action; requests at different times and older results can confuse observation. Money-write permission is not a load-testing tool.

Record how many staff sessions, which screen and how many evidence requests participated. Compare a representative session against one player read, then a single screenshot if necessary, separately. Disable extra diagnostic output after collecting a result and observe normal operation again. Collect enough comparison data to identify the responsible work, rather than maximizing data volume. This describes your current server, not a guaranteed outcome on other hardware or player counts. Confirm temporary diagnostic options were removed when closing maintenance.

Keep a small daily health record#

At the same representative time each day, keep a short maintenance record; continuous profiler or screenshot sessions are unnecessary. Include the installed version, current player count, new repeated startup errors and bridge connection state when relevant. If a staff operation is pending, inspect its status rather than multiplying the same read to measure readiness. Checking one normal character workflow and, when needed, one page is a smaller maintenance scope than walking through all history simply to collect more data.

Do not resave the entire configuration daily when settings have not changed. Compare a new doctor warning with the earlier record and record its cause; the doctor does not repair it automatically. Review a temporary exception with its owner when its review date arrives rather than inventing automatic expiry. Close an uneventful record with the observed normal state. For a new hitch or error, collect an additional measurement limited to its time and action. This is a practical administrator routine, not a new automatic task or panel feature.

Measure archive growth separately from player load#

Recorded characters, vehicles and detection history may grow while online player numbers also increase. If detection history grows tenfold at the same player count, time the first log page, a subsequent page and one known character detail separately. If archive size stays unchanged while online numbers rise, evaluate normal gameplay instead. Do not change both variables and attribute the difference solely to AC. Temporary panel results do not mean source ban or detection tables are cleaned automatically.

The first request may include table metadata preparation, while later requests can benefit from cache; record cold and warm samples separately. Supported pagination and indexes limit moving the entire archive at once but do not remove storage growth. Measure the next page in the same context rather than repeatedly loading the first. If query duration rises noticeably, ask the database maintainer to inspect plans and indexes on a test copy. Deleting history, renaming tables or exporting everything is not a performance measurement. Base maintenance decisions on data volume, player count and the measured operation together.

Register validated server actions for custom events#

Editing client exemption state does not create a server-issued blanket exemption. Local menu/integration relief is limited to movement/visibility; money, weapon and event authority remain separate. Issue broader temporary relief only from trusted server resources.

Grant narrow permissions and verify revocation#

Server-side ACE, editable administrator identifiers and panel grants determine menu access. The word all is not an identifier or a grant. allowedIds accepts full identifiers such as license:..., discord:... and fivem:... taken from the server’s player identifiers. Example text does not grant access.

  1. Give a test administrator only the required role and check menu access and one allowed action.
  2. Revoke the panel grant and retry as the same player. The updated default poll checks approximately every five seconds; network delays must be observed separately.
  3. Review independent ACE/admins.lua grants too. Online-player telemetry alone is not an authority for menu access.
  4. A normal test player must remain denied. Test money, weapons and bans without affecting real customer records.
ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Avoid unnecessary analysis after a restart#

Each startup checks resource content SHA256 fingerprints. Resources whose files and scan policy are unchanged reuse authenticated server KVP results instead of repeating expensive signature and event analysis. Changed files, exceptions or scan rules invalidate the affected analysis. Fingerprint checks still read files; no fixed resmon figure is guaranteed.

  1. Keep the KVP cache during a normal update; corrupted or unverifiable entries are analyzed again.
  2. The startup catalog collects literal event names declared in Lua/JS files. Dynamic names, unreadable or escrow files and DLLs are not certified as completely scanned.
  3. Manual automatic setup waits for security analysis. Incomplete, suspicious, changed or timed-out resources are never automatically approved.
  4. Test player joins, normal gameplay and admin actions on a staging server, and interpret resmon alongside player count and framework load.