OpenClaw Performance
Verschwendung ist Arbeit, die eine Anfrage nicht benötigt. Große Beschleunigungen entstehen durch das Löschen von Verschwendung, nicht durch das schneller Erledigen derselben Arbeit. Ein Cache ist das letzte Mittel: Er versteckt Verschwendung, bis sein Schlüssel, seine Invalidierung oder Trefferrate bricht und die Verschwendung zurückkehrt.
1. Messen
Schreibe die Akzeptanzregel in den PR vor dem ersten Durchlauf: Ablauf, Arbeitslast, Metrik, kalt oder warm, Stichproben und die Änderung, die als Gewinn oder Regression zählt.
| Ablauf | Festgelegte Arbeitslast |
|---|---|
| CLI-Start | pnpm test:startup:bench (:check enthält das Budget) |
| Gateway-Start / -Neustart | scripts/bench-gateway-startup.ts, scripts/bench-gateway-restart.ts, scripts/perf/post-restart-burst-measure.ts |
| Chat-Turn, Frames pro Turn | scripts/bench-channel-turn.mts, scripts/perf/transcript-broadcast-measure.ts |
| Control UI kalter Start | scripts/bench-control-ui-cold-load.ts, pnpm ui:check-performance (:base vergleicht) |
| Sitzungsliste, Multi-Agent-Form | scripts/perf/team-shape-fixture.ts, src/gateway/session-list-viewers.perf.test.ts |
| Nebenläufigkeit, SQLite-Zustand | scripts/bench-gateway-concurrency.ts, pnpm test:sqlite:perf |
- Zuerst zählen: Operationen pro Aktion (SQL-Anweisungen, RPCs und Frames, Dateilesevorgänge, Katalog- oder Registry-Ladevorgänge, Spawns, Renderings) vor der Wanduhrzeit. Zählungen bleiben auf einem ausgelasteten Rechner stabil. Eine Zählung, die Null sein sollte, ist der Fehler.
- Echter Ablauf: ein isoliertes Gateway auf dem zu testenden Head, echter Transport, der langsame Pfad eingeschlossen. Ein Mock-Gateway, ein alter Build oder ein Dev-Server misst etwas anderes.
- Stichproben: Basislinie und Kandidat verschachtelt (ABAB), mindestens 5 jeweils, kalt und warm getrennt; Median und p95 mit Streuung, seriell ausgeführt, Host-Auslastung aufgezeichnet.
- Wiederholbar: nur festgelegte Skripte zählen; erweitere ein vorhandenes, wenn keins passt.
- Profil:
node --cpu-profpro Thread oder ein Browser-Performance-Trace auf dem heißen Pfad.
Erledigt, wenn der Ablauf eine festgelegte Arbeitslast, eine Basistabelle und eine schriftliche Regel hat.
2. Verschwendung finden
Frage bei jeder gezählten Operation: Benötigt diese Anfrage sie? Wiederkehrende Verschwendung in OpenClaw:
- Eager Work im kritischen Pfad: Eine Registry-Suche importierte den Plugin-Loader (#133518, 47,07 s → 10,36 s); optionale Laufzeiten wurden beim Start geladen (#119374).
- Neuberechnung pro Zeile oder pro Aufruf: Ein synchroner Lesevorgang pro archivierter Zeile (#156665, 56.700 Lesevorgänge → 0); Log-Muster wurden pro Frame aufgelöst (#150042, 539 → 17 ms pro 10.000 Frames).
- Erneutes Prüfen des bekannten Zustands: Schema-, Zulassungs- oder Frischeprüfungen bei warmen Handles (#166102, #172676; 14 PRs in der SQLite-Zulassungskette).
- Vollständiger erneuter Scan pro gestreamtem Delta: Jedes Token verarbeitete die gesamte Antwort erneut (#158526, 5.342 → 1 ms CPU bei 256 KiB).
- Erneutes Lesen des eigenen Schreibvorgangs: Zwei Datenbanksicherungen pro Suche (#161551, 772,8 → 7,7 ms); Doctor hat das gerade Geprüfte erneut gescannt und gesichert (#174665, ~26 → 3,0 s).
- Wiederholte Katalog- oder Registry-Erstellungen: Ein pro Agent durchgeführter Katalog-Neubau beim Start (#116261, 24,9 → 5,0 s); Neubauten pro Fehlzugriff oder TTL (#127178, #167008).
- Warten auf optionale Daten: Die Nutzungsseite wartete auf Anbieterpläne und wiederholte nicht verwandte Lesevorgänge (#176358).
- Defensive Kopien und Wrapper:
structuredClonepro Turn (#172940, 1,685 MiB → 0); Boundary-Wrapping pro Wert (#163818, 11.571 → 500 ns/Ereignis). - Spawn oder Fan-out pro Aufruf: Ein Kindprozess pro Auflösung (#155779, 100 → 0).
- Render-Kaskaden und vollständige Payloads: Ein Rendering pro Aktualisierung (#159400, 250 → 79); vollständige Zeilen für ein Delta erneut gesendet (#165404, 21,75 → 0,95 MB).
Erledigt, wenn jede dominante Zählung auf den Code zurückverfolgt werden kann, der sie ausgibt, mit einem Ja oder Nein auf „benötigt".
3. In dieser Reihenfolge beheben
- Lösche die Verschwendung. Löschungen kommen selten zurück; ein fehlgeschlagenes Löschen entfernte eine Sicherung, also behalte jede Prüfung, die einen Vertrag schützt, und beweise, dass der Vertrag weiterhin gilt.
- Einmal beim Besitzer: Aufrufer konsumieren die aufgezeichnete Tatsache des Besitzers.
- Trage die vorbereitete Tatsache durch den heißen Pfad.
- Batches von unabhängiger Arbeit, und beweise, dass der Batch Frames, Latenzschwänze und Kaltstart stabil hält: Zusammenführung wurde dreimal zurückgesetzt (#162560, #173901, #175092).
- Cache, mit einem schriftlichen Grund, warum die Schritte 1–4 nicht zutreffen. Befolge root „Cache-Identität", invalidiere anhand der Schreibvorgänge des Besitzers, begrenze die Größe und füge einen verschachtelten Arbeitszählungstest hinzu. Drei von vier Cache-Nachbesserungen waren stille Fehltreffer: Leser, die sich gegenseitig verdrängten (#115369 → #174741), ein Budget, das thrash-te (#149773 → #149879).
Eine Worker-Verschiebung oder ein Aufschub verlagert Kosten; zähle Haupt-Thread- und Gesamtarbeit.
Erledigt, wenn die Verschwendung aus den Zählungen verschwunden ist oder der PR sagt, welcher Schritt gestoppt wurde und warum.
4. Einreichen
- Führe die Arbeitslast aus Schritt 1 auf Basislinie und Kandidat unter derselben Regel erneut aus.
- Jede benutzerorientierte Metrik bleibt gleich oder verbessert sich: Latenz, p95/p99, Frames, Kaltstart, CPU, Speicher, Zählungen. Eine schlechtere Metrik benötigt die ausdrückliche Zustimmung des Besitzers im PR. Eine 20 %-Verschiebung in einer Zelle ist ein Stopp, niemals „innerhalb der Streuung": Fünf von sechs zurückgesetzten Performance-PRs zeigten ihre Regression in ihrem eigenen Text.
- Änderungen ohne messbaren Gewinn zurücknehmen.
- Der Beweis lebt im PR, nicht in neuen Tests: die Vorher-/Nachher-Zählungen sind der Beleg. Erweitere den vorhandenen Arbeitszählungstest eines Ablaufs nur, wenn diese Verschwendung schon einmal zurückgekommen ist; test-audit besitzt den Testwert.
- PR-Beweise: Arbeitslastbefehl, Akzeptanzregel, Vorher-/Nachher-Tabelle (Zählungen und Zeiten, Median und p95, Stichproben), entfernte Verschwendung und jede Metrik, die sich in die falsche Richtung bewegt hat.
Erledigt, wenn die Tabelle die in Schritt 1 geschriebene Regel erfüllt.
Verwandtes
Test-Suite-Geschwindigkeit: openclaw-test-performance. Test-Heap-Wachstum: openclaw-test-heap-leaks. CI-Kapazität: openclaw-ci-limits.