Zur Anleitung

Dokumentation 9.6.24

Einstellungen und Leistung

Auf dem eigenen Server messen. Ressourcen, Spielerzahl, Aufnahmen und Indizes beeinflussen die Last; keine Garantie für verzögerungsfreien Betrieb.

Zuerst beobachten#

Erkennungen vor Kick-/Ban-Regeln mit normalem Spiel vergleichen. Teleports, Respawns und legitime Waffenvergabe testen. Client-Signale dürfen keine Geld-, Waffen- oder Admin-Rechte verleihen.

Aufwendige Funktionen gezielt nutzen#

Tiefe Scans und automatische Quarantäne ohne Tests deaktiviert lassen. Gleichzeitige Aufnahmen begrenzen. Die Bridge liest im Leerlauf keine Spieldaten; HTTPS-Statusabfragen und andere Module benötigen weiterhin Ressourcen. Änderungen mit dem FiveM-Profiler messen.

Vergleichbare Ausgangsmessung#

Profilieren Sie vor Änderungen eine typische Sitzung. Notieren Sie Spielerzahl, Artifact, Ressourcenversionen und Aktivitäten. Ruhiges Rollenspiel, volle Garagen und Gefechte unterscheiden sich. Vergleichen Sie nach einer einzelnen Änderung denselben Ablauf. CPU-Zeit, Hitches und Abfragen sind aussagekräftiger als feste FPS-Versprechen.

Die Befehle zeichnen eine begrenzte Probe auf. Nach Abschluss öffnen und die verursachende Ressource und den Thread prüfen. Nicht jeden Hitch der AC zuordnen. Geänderten Wert und Vorher/Nachher privat notieren; kurze Proben decken nicht jede Spitzenlast ab.

profiler record 500
profiler status
profiler view

tosunac_doctor

Last reduzieren und Schutz erhalten#

Optionale tiefe Scans und automatische Quarantäne erst kontrolliert testen. Gleichzeitige Live-Aufnahmen begrenzen und Debug im Betrieb ausschalten. Kürzere Prüf- oder Pollingintervalle bedeuten mehr Arbeit, nicht automatisch bessere Bedienung.

  1. Leerlauf und eine Panel-Leseanfrage getrennt messen. Die Bridge liest im Leerlauf kein Spiel-SQL; HTTPS und andere Module brauchen dennoch Ressourcen.
  2. Große Listen seitenweise lesen; verweigerte Indexzugriffe mit dem Datenbankverantwortlichen prüfen.
  3. Eine Testaufnahme messen, bevor mehrere Teammitglieder gleichzeitig zuschauen.
  4. Bei gestiegener Last den geänderten Wert zurücksetzen und denselben Ablauf erneut prüfen.

Strafen mit Kontext bewerten#

Kontextabhängige Prüfungen erst beobachten und normales Spielen testen. Ein Logsignal ist kein pauschaler Bannauftrag. Charakterwahl, Wiederbelebung, Teleports, Polizeiausrüstung und Skriptwaffen prüfen. Gezielte Integration statt dauerhafter Gesamtausnahme.

tosunac_doctor zeigt riskante effektive Werte, verändert nichts. Warnungen zu harten Strafen, ausgeschalteten Sicherungen, Debug und Fail-open prüfen. Panelwerte können lokale Defaults überschreiben; aktive Werte beurteilen.

Ausnahmen oder mildere Aktionen können Beschwerden verbergen, ohne Ursachen zu lösen. Temporäre Ausnahmen mit Datum und betroffenem Skript notieren. Nach geprüfter Integration Ausnahme entfernen und denselben Spielablauf samt Logs vergleichen.

  • Ein Wert pro Änderung; Grund, Prüfer und vorherigen Wert notieren.
  • Wiederholte Signale mit legitimen Aktionen und Zeiten abgleichen.
  • Nach Strafen-, Core- oder Inventaränderung erneut testen.
  • Bei neuen Fehlalarmen zurücksetzen und Ursache vor erneutem Verschärfen beheben.

Dieselbe Belastung vor und nach Änderungen messen#

Notieren Sie Spielerzahl, Artifact-, AC-, Framework- und Inventarversion sowie aktive Panelvorgänge. Messen Sie zuerst eine ruhige Sitzung ohne Panelaufträge, anschließend typische Charakterauswahl, Garagennutzung und Kämpfe. profiler record 500 erstellt eine begrenzte Aufzeichnung; prüfen Sie mit profiler status deren Abschluss.

Ermitteln Sie in profiler view die Resource und den Thread eines CPU-Spitzenwerts. Beachten Sie wiederholt lange Ausführungen und passende Hitch-Warnungen. Ändern Sie nur eine Einstellung und wiederholen Sie den Ablauf bei ähnlicher Spielerlast. Für Probleme zu Stoßzeiten ist eine entsprechende Sitzung erforderlich; mehrere gleichzeitige Änderungen verhindern eine klare Zuordnung.

Arbeit der Datenbankbrücke getrennt betrachten#

Gesundheitskommunikation bedeutet nicht, dass die Brücke im Leerlauf ständig Spielerlisten aus der Spieldatenbank liest. Sie verwaltet jeweils eine ausgehende Anfrage. Der normale Gesundheitszyklus beträgt ungefähr zehn Sekunden; bei Fehlern steigt die Wartezeit bis höchstens zwei Minuten. Das beschreibt die Implementierung, keine einstellbare Geschwindigkeit oder garantierte Aktualisierungsfrist.

Prüfen Sie lokal mit tosunac_db_status. Vergleichen Sie eine Spielerlistenseite mit der Leerlaufmessung. Listen sind auf Seiten mit 25 Einträgen und begrenzte Antwortgrößen ausgelegt. Bei unsupported_index oder schema_unavailable prüfen Sie unterstütztes Schema und Indizes mit einer berechtigten Datenbankverwaltung, statt größere Abfragen zu erzwingen.

Abnahme und Rückkehr zum vorherigen Wert festhalten#

Legen Sie serverbezogene Kriterien fest: keine neuen dauerhaften Hitch-Warnungen, vollständige normale Spielabläufe und erklärbare Zeitsteigerungen. Universelle FPS-Ziele berücksichtigen weder Spielerhardware noch andere Resources. Ein schnelleres Profil rechtfertigt keine falschen Erkennungen.

Dokumentieren Sie alte und neue Werte, Zeit, Spielerzahl und Wirkung. Steigt die Last, setzen Sie genau die geänderte Einstellung zurück und wiederholen Sie den Test. Ändern Sie für Messungen keine Kontostände. Teilen Sie bereinigte Profilzusammenfassungen und Doctor-Warnungen mit Support. Kontrollieren Sie anschließend eine normale Produktionssitzung, damit besondere Testbedingungen die tatsächliche Last nicht verdecken.

Einzelnen Spitzenwert von wiederkehrender Arbeit unterscheiden#

Ändern Sie Einstellungen nicht allein wegen der längsten Profilzeile. Prüfen Sie wiederholt laufende Resource und Thread sowie die passende Aktion. Einmalige Vorbereitung beim Beitritt unterscheidet sich von jedem Tick. Bei einem Spitzenwert nur beim ersten Garagenöffnen vergleichen Sie weitere Öffnungen. Haben sich andere Resources geändert, ist die Differenz nicht allein dem AC zuzuordnen. Kurze Aufzeichnungen decken nicht alle Spitzenzeiten ab.

Notieren Sie Dauer, Häufigkeit und Aktion zusammen. Viele kurze Abläufe können Gesamtzeit erzeugen, während ein langer Ablauf gleichzeitig mit einem Hitch auftritt. Serverprofiler-Zeit ist keine Client-FPS-Anzeige. Vergleichen Sie Clientaussetzer zeitlich mit dem Server; Netzlatenz und Assets benötigen eventuell eigene Prüfung. Bitten Sie mit bereinigtem Ausschnitt und Szenario um Unterstützung, statt bei Unklarheit alle Erkennungsintervalle zu verkürzen.

Kosten der Beobachtung mitmessen#

Überwachung und Diagnose erzeugen ebenfalls Arbeit. Lange Aufzeichnung, viele Panelabfragen, Beweisbilder und dauerhafte Debug-Ausgabe gemeinsam erschweren die Zuordnung. Begrenzen Sie Werkzeuge zunächst und vergleichen Sie dann ein aktiviertes Werkzeug. Mehrere aktualisierte Tabs verbessern die Messung derselben Spieleraktion nicht; unterschiedliche Zeitpunkte und alte Ergebnisse können sie verfälschen. Geldschreibrechte dienen nicht als Lasttest.

Erfassen Sie Mitarbeiter-Sitzungen, Bildschirm und Anzahl der Beweisanfragen. Vergleichen Sie normale Sitzung, eine Spielerabfrage und gegebenenfalls ein Bildschirmfoto getrennt. Schalten Sie zusätzliche Diagnose danach ab und beobachten Sie Normalbetrieb. Sammeln Sie genügend Daten zur Zuordnung, nicht möglichst viele. Ergebnisse gelten für Ihren aktuellen Server, ohne Zusage für andere Hardware oder Spielerzahl. Prüfen Sie zum Wartungsabschluss, dass temporäre Diagnoseoptionen entfernt wurden.

Ein kleines tägliches Gesundheitsprotokoll führen#

Führen Sie täglich zur gleichen repräsentativen Zeit ein kurzes Wartungsprotokoll; dauerhafte Profiler- oder Screenshot-Sitzungen sind nicht erforderlich. Erfassen Sie installierte Version, aktuelle Spielerzahl, neue wiederholte Startfehler und gegebenenfalls den Brückenstatus. Prüfen Sie einen offenen Personalauftrag anhand seines Status statt identische Leseaufträge zur Verfügbarkeitsmessung zu vervielfachen. Ein normaler Charakterablauf und bei Bedarf eine Seite bilden eine kleinere Wartung als das Durchlaufen der gesamten Historie ohne konkreten Anlass.

Speichern Sie unveränderte Einstellungen nicht täglich erneut. Vergleichen Sie eine neue Doctor-Warnung mit dem früheren Protokoll und notieren Sie ihre Ursache; der Doctor repariert nicht automatisch. Besprechen Sie eine vorübergehende Ausnahme zum vereinbarten Prüftermin mit dem Verantwortlichen, statt einen automatischen Ablauf zu erfinden. Ohne neue Auffälligkeit genügt der beobachtete Normalzustand. Bei einem neuen Hitch oder Fehler messen Sie zusätzlich gezielt die betreffende Zeit und Aktion. Dies ist eine praktikable Verwaltungsroutine, keine neue automatische Aufgabe oder Panel-Funktion.

Archivwachstum getrennt von Spielerlast messen#

Gespeicherte Charaktere, Fahrzeuge und Erkennungshistorie können wachsen, während gleichzeitig mehr Spieler online sind. Wächst die Erkennungshistorie bei gleicher Spielerzahl um das Zehnfache, messen Sie erste Log-Seite, Folgeseite und einen bekannten Charakter getrennt. Steigt die Spielerzahl bei unverändertem Archiv, untersuchen Sie hingegen normales Spielen. Ändern Sie nicht beide Größen und schreiben die Differenz allein AC zu. Vorübergehende Panel-Ergebnisse bedeuten keine automatische Reinigung der ursprünglichen Ban- oder Erkennungstabellen.

Die erste Anfrage kann Tabellenmetadaten vorbereiten, spätere profitieren vom Cache. Notieren Sie kalte und warme Messungen getrennt. Seitennavigation und Indizes begrenzen die Übertragung des gesamten Archivs, beseitigen aber kein Speicherwachstum. Messen Sie die nächste Seite im selben Kontext statt wiederholt die erste. Bei deutlich längeren Abfragen sollte der Datenbankverantwortliche Pläne und Indizes an einer Testkopie prüfen. Historie löschen, Tabellen umbenennen oder alles exportieren ist keine Leistungsmessung. Datenumfang, Spielerzahl und gemessener Vorgang sollen die Wartungsentscheidung gemeinsam stützen.

Eigene Events mit Serverprüfung registrieren#

Vom Client geänderte Ausnahmewerte erteilen keine umfassende Serverausnahme. Lokale Menü-/Integrationshilfen gelten begrenzt für Bewegung/Sichtbarkeit; Geld-, Waffen- und Eventrechte bleiben separat. Breite Ausnahmen nur von vertrauenswürdigen Serverresources vergeben.

Menürechte vergeben und Entzug prüfen#

ACE, Administrator-IDs und Panel-Freigaben werden serverseitig geprüft. all allein ist weder ID noch Freigabe. allowedIds benötigt vollständige license:..., discord:... oder fivem:... aus der Spieler-ID-Liste des Servers.

  1. Testadministrator mit den erforderlichen Rechten prüfen.
  2. Panel-Freigabe entfernen und denselben Spieler erneut prüfen; die neue Standardabfrage läuft ungefähr alle fünf Sekunden.
  3. Unabhängige ACE/admins.lua-Freigaben ebenfalls prüfen. Online-Spieler-Telemetrie ist keine Berechtigung.
  4. Ein normaler Testspieler muss abgewiesen bleiben; sensible Aktionen nur mit Testdaten prüfen.
ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Unnötige Analyse nach Neustarts vermeiden#

Bei jedem Start werden SHA256-Inhaltsprüfsummen der Ressourcen geprüft. Unveränderte Dateien und Scanregeln verwenden authentifizierte Ergebnisse im Server-KVP statt aufwendiger Signatur- und Ereignisanalyse. Geänderte Dateien, Ausnahmen oder Regeln lösen neue Analysen aus. Die Prüfsummenprüfung liest weiterhin Dateien; ein fester resmon-Wert wird nicht garantiert.

  1. Den KVP-Cache bei normalen Updates behalten; beschädigte oder nicht verifizierbare Einträge werden erneut analysiert.
  2. Der Startkatalog erfasst wörtlich deklarierte Lua/JS-Ereignisnamen. Dynamische Namen, unlesbare oder Escrow-Dateien und DLLs gelten nicht als vollständig geprüft.
  3. Die manuelle automatische Einrichtung wartet auf die Sicherheitsanalyse. Unvollständige, verdächtige, geänderte oder abgelaufene Ressourcen werden nicht automatisch freigegeben.
  4. Spielerbeitritt, normales Spiel und Administratoraktionen auf einem Testserver prüfen; resmon zusammen mit Spielerzahl und Framework-Last bewerten.