openclaw-performance

OpenClaw – Performances

Le gaspillage est le travail dont une requête n'a pas besoin. Les grandes accélérations viennent de la suppression du gaspillage, pas de l'exécution plus rapide du même travail. Un cache est le dernier recours : il masque le gaspillage jusqu'à ce que sa clé, son invalidation ou son taux de succès échoue, et le gaspillage réapparaît.

1. Mesurer

Écrivez la règle d'acceptation dans la PR avant la première exécution : flux, charge de travail, métrique, à froid ou à chaud, échantillons, et le changement qui constitue un gain ou une régression.

Flux	Charge de travail validée
Démarrage CLI	pnpm test:startup:bench (:check contient le budget)
Démarrage / redémarrage Gateway	scripts/bench-gateway-startup.ts, scripts/bench-gateway-restart.ts, scripts/perf/post-restart-burst-measure.ts
Tour de chat, images par tour	scripts/bench-channel-turn.mts, scripts/perf/transcript-broadcast-measure.ts
Chargement à froid UI Contrôle	scripts/bench-control-ui-cold-load.ts, pnpm ui:check-performance (:base compare)
Liste de sessions, forme multi-agent	scripts/perf/team-shape-fixture.ts, src/gateway/session-list-viewers.perf.test.ts
Concurrence, état SQLite	scripts/bench-gateway-concurrency.ts, pnpm test:sqlite:perf

• D'abord les comptages : opérations par action (instructions SQL, RPC et images, lectures de fichiers, chargements de catalogue ou registre, spawns, rendus) avant le temps réel. Les comptages restent stables sur une machine chargée. Un comptage qui devrait être nul est le bogue.
• Flux réel : un Gateway isolé sur le commit testé, transport réel, chemin lent inclus. Un Gateway simulé, une build périmée ou un serveur de développement mesure autre chose.
• Échantillons : référence et candidat entrelacés (ABAB), au moins 5 chacun, séparés à froid et à chaud ; médiane et p95 avec dispersion, exécutés en série, charge de la machine enregistrée.
• Reproductible : seuls les scripts validés comptent ; étendez-en un existant si aucun ne convient.
• Profilage : node --cpu-prof par thread, ou une trace de performance navigateur, sur le chemin chaud.

Terminé lorsque le flux a une charge de travail validée, un tableau de référence et une règle écrite.

2. Trouver le gaspillage

Demandez pour chaque opération comptée : cette requête en a-t-elle besoin ? Gaspillages récurrents dans OpenClaw :

• Travail anticipé sur le chemin critique : une recherche de registre a importé le chargeur de plugin (#133518, 47,07 s → 10,36 s) ; des runtimes optionnels chargés au démarrage (#119374).
• Re-calcul par ligne ou par appel : une lecture synchrone par ligne archivée (#156665, 56 700 lectures → 0) ; motifs de logs résolus par image (#150042, 539 → 17 ms pour 10 000 images).
• Vérification répétée d'un état admis : vérifications du schéma, d'admission ou de fraîcheur sur des connexions chaudes (#166102, #172676 ; 14 PR dans la chaîne d'admission SQLite).
• Rescan complet par delta streamé : chaque token retraitait la réponse entière (#158526, 5 342 → 1 ms CPU à 256 Kio).
• Relecture de sa propre écriture : deux sauvegardes de base de données par recherche (#161551, 772,8 → 7,7 ms) ; Doctor rescannait et sauvegardait ce qu'il venait de vérifier (#174665, ~26 → 3,0 s).
• Reconstructions répétées de catalogue ou registre : reconstruction de catalogue par agent au démarrage (#116261, 24,9 → 5,0 s) ; reconstructions par échec ou TTL (#127178, #167008).
• Attente de données optionnelles : la page Utilisation attendait les plans des fournisseurs et réessayait des lectures non liées (#176358).
• Copies défensives et encapsulations : structuredClone par tour (#172940, 1,685 Mio → 0) ; encapsulation par valeur de limite (#163818, 11 571 → 500 ns/événement).
• Spawn ou fan-out par appel : un processus enfant par résolution (#155779, 100 → 0).
• Cascades de rendu et charges utiles complètes : un rendu par mise à jour (#159400, 250 → 79) ; lignes complètes renvoyées pour un delta (#165404, 21,75 → 0,95 Mo).

Terminé lorsque chaque comptage dominant trace le code qui l'émet, avec un oui ou non sur « nécessaire ».

3. Corriger dans cet ordre

1. Supprimer le gaspillage. Les suppressions reviennent rarement ; une suppression ratée a retiré une garde, alors conservez chaque vérification qui protège un contrat et prouvez que le contrat tient toujours.
2. Une fois chez le propriétaire : les appelants consomment le fait enregistré du propriétaire.
3. Porter le fait préparé à travers le chemin chaud.
4. Regrouper le travail indépendant, et prouvez que le regroupement maintient les trames, les queues de latence et le démarrage à froid stables : le regroupement a été annulé trois fois (#162560, #173901, #175092).
5. Cacher, avec une raison écrite pour laquelle les étapes 1–4 ne s'appliquent pas. Suivez « l'identité du cache racine », invalidez à partir des écritures du propriétaire, limitez la taille, et ajoutez un test de comptage entrelacé. Trois des quatre corrections de cache étaient des échecs silencieux : des lecteurs s'évincant mutuellement (#115369 → #174741), un budget qui thrashait (#149773 → #149879).

Un déplacement vers un worker ou un report déplace le coût ; comptez le travail sur le thread principal ET le travail total.

Terminé lorsque le gaspillage a disparu des comptages, ou la PR indique quelle étape s'est arrêtée et pourquoi.

4. Livrer

• Réexécutez la charge de travail de l'étape 1 sur la référence et le candidat avec la même règle.
• Chaque métrique utilisateur se maintient ou s'améliore : latence, p95/p99, images, démarrage à froid, CPU, mémoire, comptages. Une métrique moins bonne nécessite l'acceptation explicite du propriétaire dans la PR. Un déplacement de 20 % dans une cellule est un arrêt, jamais « dans la dispersion » : cinq des six PR de performance annulées montraient leur régression dans leur propre corps.
• Annulez les changements sans gain mesurable.
• La preuve vit dans la PR, pas dans de nouveaux tests : les comptages avant/après sont la preuve. Étendez le test de comptage existant d'un flux seulement lorsque ce gaspillage est déjà revenu ; test-audit possède la valeur des tests.
• Preuve de la PR : commande de charge de travail, règle d'acceptation, tableau avant/après (comptages et temps, médiane et p95, échantillons), gaspillage supprimé, et toute métrique ayant évolué dans le mauvais sens.

Terminé lorsque le tableau satisfait la règle écrite à l'étape 1.

Liens connexes

Vitesse des suites de tests : openclaw-test-performance. Croissance du tas des tests : openclaw-test-heap-leaks. Capacité CI : openclaw-ci-limits.