§ BENCHMARKS
Enforcement-Latenz, ehrlich gemessen
Governance funktioniert nur, wenn sie schnell genug ist, um im Anfragepfad zu liegen. Diese Seite dokumentiert, wie wir die Enforcement-Latenz und den Durchsatz von Execlave messen — und veröffentlicht die Zahlen, sobald sie nach dieser Methodik gemessen wurden.
Die unten aufgeführten Pattern-Tier-, Labor- und Produktions-Enforce-Werte sowie die Kill-Switch-Werte sind gemessen durch eingecheckte Test-Harnesses (siehe Methodik). Der semantische Tier und der skalierte Durchsatz sind als noch nicht veröffentlicht markiert — wir veröffentlichen nur Werte, die nach der Methodik auf dieser Seite gemessen wurden, niemals Schätzungen oder marketingtaugliche Rundungen.
§ ERGEBNISSE
Pattern-Tier — gemessen
In-Process-Latenz der Richtlinienauswertung (parse-gecachtes CEL), ohne Netzwerk- und Datenbankzeit.
§ ERGEBNISSE
Serverseitige Enforce-Entscheidung — Labor (lokales Postgres)
Der reale PolicyService.enforcePreExecution-Pfad: Agentenstatusabfrage + Richtlinienladen + Auswertung, inklusive Datenbank, gegen eine lokale Postgres-Instanz. Ohne HTTP-/Auth-Rahmen und den modellbasierten semantischen Tier.
§ ERGEBNISSE
Enforce-Entscheidung in Produktion — api.execlave.com
Gemessen am 29. Oktober 2026 gegen die verwaltete Cloud (EU West, Amsterdam): 300 aufeinanderfolgende Enforce-Aufrufe nach 5 Aufwärmaufrufen, für einen Agenten, der gegen die beiden organisationsweiten Injection-Scan-Richtlinien unserer eigenen Produktionsorganisation geprüft wurde. Die serverseitige Zeit stammt aus dem Server-Timing-Header jeder Antwort und ist die Summe aus API-Key-Authentifizierung und Enforce-Handler; das Netzwerk zwischen Client und API ist nicht enthalten. Bei diesen Aufrufen lief keine modellbasierte semantische Prüfung.
§ ERGEBNISSE
Kill-Switch — Labor (lokales Postgres)
Server-seitige Kosten des Wirksamwerdens der Pause: die reale AgentService.pause-Transaktion (BEGIN + SET LOCAL + Status-SELECT/UPDATE + COMMIT), inklusive Datenbank, unter der app_user-Rolle mit aktivierter RLS. Die Propagation ist synchron — die erste Richtlinienprüfung nach dem Commit der Pause ist bereits blockiert. Ohne HTTP-/Auth-Rahmen und Netzwerk; ein Client über HTTP zahlt zusätzlich Auth pro Anfrage und Round-Trip-Latenz.
§ ERGEBNISSE
Kill-Switch in Produktion — api.execlave.com
Gemessen am 30. Oktober 2026 gegen die verwaltete Cloud (EU West, Amsterdam): 30 Pausen eines temporären Agenten über PATCH /api/v1/agents/:id/status mit einem API-Key, jeweils gefolgt von Enforce-Aufrufen, bis einer blockiert wurde. Die serverseitige Zeit stammt aus dem Server-Timing-Header jeder Pause-Antwort: API-Key-Authentifizierung plus die Transaktion, die den Agenten auf pausiert setzt und den Audit-Eintrag an die Hash-Kette anhängt. Die Pause ist wirksam, sobald diese Transaktion committet ist. Nicht enthalten sind das Netzwerk zwischen Client und API und die Benachrichtigungen nach dem Commit (Dashboard-Ereignis, SDK-Steuerkanal, Webhook-Versand).
§ ERGEBNISSE
Semantischer Tier & skalierter Durchsatz — ausstehend
Dominiert vom gewählten LLM (semantischer Tier) und der Worker-Skalierung (Durchsatz). Wird vor der Veröffentlichung auf repräsentativer Infrastruktur gemessen — niemals geschätzt.
§ METHODIK
Wie wir messen
Damit die veröffentlichten Zahlen reproduzierbar und über Releases hinweg vergleichbar sind.
Was die gemessenen Werte abdecken
Die Pattern-Tier-Zahlen beziehen sich auf die In-Process-Kosten der Auswertung eines Traces gegen eine Reihe von Richtlinien in der Enforcement-Engine (parse-gecachte CEL-Ausdrucksauswertung), ohne Netzwerk- und Datenbankzeit. Dies ist der Teil der Enforcement-Latenz, den Execlave direkt steuert; er wird als p50/p95/p99 angegeben, nicht als Durchschnitt, da Tail-Latenz für Governance-SLAs entscheidend ist.
Herkunft der Messung
Gemessen auf Node.js v22.20.0, ein Prozess, ein Kern, Caches vorgewärmt. Jeder „Durchlauf“ wertet einen repräsentativen Satz von 5 Ausdrucksrichtlinien (Kosten-, Größen- und Umgebungsvergleiche) gegen einen Trace über 200.000 Iterationen nach einem Warmup von 20.000 Iterationen aus. Das Test-Harness ist unter backend/scripts/bench-enforcement.ts eingecheckt und ruft denselben evaluateExpression-Pfad auf, den die Laufzeitumgebung verwendet — führen Sie es erneut aus, um diese Werte auf Ihrer eigenen Hardware zu reproduzieren.
End-to-End-Messung
Die server-seitigen Werte stammen vom realen PolicyService.enforcePreExecution-Pfad gegen eine laufende Postgres-Instanz — Agentenstatusabfrage, Richtlinienladen und Ausdrucksauswertung, jeder Datenbank-Roundtrip, den der SDK-Enforce-Endpunkt durchführt, unter der Least-Privilege-App-Rolle mit aktivierter Row-Level-Security. Gemessen auf Node.js v22.20.0 gegen eine lokale Postgres-Instanz (Netzwerk im Sub-Millisekundenbereich), 5.000 Aufrufe nach einem Warmup von 500 Aufrufen; das Test-Harness ist unter backend/scripts/bench-enforce-e2e.ts eingecheckt. Ausgeschlossen sind der HTTP-/Auth-Rahmen (Sub-Millisekundenbereich, kein „Enforcement“) und der modellbasierte semantische Tier. Datenbank-Roundtrips in der Produktion sind langsamer als auf localhost — betrachten Sie diese Werte daher als Untergrenze, nicht als Obergrenze.
Messung in Produktion
Die Produktionswerte stammen aus dem Test-Harness unter backend/scripts/bench-enforce-prod.mjs. Es legt einen temporären Agenten an, sendet Aufwärm- und Messaufrufe nacheinander von einem einzelnen Client, liest den Server-Timing-Header jeder Antwort, gibt Perzentile der Summe aus Authentifizierungs- und Handler-Zeit je Anfrage aus und löscht den Agenten wieder. Innerhalb unserer Hosting-Region dauert jeder Datenbank- oder Redis-Roundtrip derzeit etwa 5 ms. Die serverseitige Zeit besteht daher überwiegend aus den drei verbleibenden Roundtrips (Schlüsselabfrage, Mandantenkontext, Kontingent und Agent), nicht aus der Richtlinienauswertung. Der Roundtrip eines Clients hängt von seiner Entfernung nach Amsterdam ab; auch ein Client in derselben Region geht über den öffentlichen API-Edge. Ein zweiter Lauf am selben Tag aus der Region heraus ergab serverseitig im Median 21,2 ms (p99 25,4 ms); zwischen Läufen sind also ein bis zwei Millisekunden Schwankung zu erwarten. Ändert sich die Infrastruktur, wird die Tabelle neu gemessen und neu datiert.
Messung des Kill-Switch
Die Produktionswerte des Kill-Switch stammen aus backend/scripts/bench-killswitch-prod.mjs. In jeder Runde setzt das Skript einen temporären Agenten wieder aktiv, pausiert ihn mit einem API-Aufruf, sendet Enforce-Aufrufe, bis einer blockiert wird, und liest den Server-Timing-Header der Pause-Antwort; am Ende löscht es den Agenten. Die Transaktion macht den größeren Anteil aus, weil sie etwa acht aufeinanderfolgende Datenbank-Roundtrips zu je etwa 5 ms braucht: Sie liest und aktualisiert den Agenten und hängt den Audit-Eintrag unter einer Sperre an die Hash-Kette der Organisation an. Eine Pause aus dem Dashboard läuft durch denselben Dienst, authentifiziert sich aber mit einer Sitzung statt eines API-Keys; deren Authentifizierungszeit wurde hier nicht gemessen.
Was NICHT in diesen Zahlen enthalten ist
Der semantische Tier (modellbasierte Prüfungen über den Python-Verarbeitungsdienst) hängt vom gewählten LLM ab und ist noch nicht veröffentlicht. Horizontal skalierter Durchsatz (Traces/Sek. über mehrere Worker) ist ebenfalls noch nicht veröffentlicht. Wir vermischen die Mikrosekunden-Auswertung, die Millisekunden-Server-Entscheidung und den modellbasierten Tier nicht zu einer einzigen Kennzahl, und wir schätzen die noch nicht gemessenen Tiers nicht. Die serverseitigen Laborwerte stammen aus einem Lauf gegen ein lokales Postgres; die Produktionswerte enthalten zusätzlich Roundtrips zur verwalteten Datenbank und die API-Key-Authentifizierung und sind deshalb höher. Jede Enforce-Antwort in Produktion meldet ihre serverseitige Dauer im Server-Timing-Header.
Warum pro Tier, niemals vermischt
Pattern-Tier (In-Process, Mikrosekundenbereich) und semantischer Tier (modellbasiert, Millisekunden- bis Sekundenbereich) unterscheiden sich um Größenordnungen. Eine einzige „Enforcement-Latenz“-Kennzahl wäre irreführend, daher wird jeder Tier separat ausgewiesen und genau beschrieben, was er umfasst.
Messen Sie es in Ihrem eigenen Stack
Kostenloser Tarif verfügbar. Keine Kreditkarte erforderlich.