Die meisten Leistungsversprechen auf dem Markt für Regel-Engines sind nicht überprüfbar. Aussagen wie „Antwortzeiten unter einer Sekunde“, „massive Skalierbarkeit“ oder „Durchsatz auf Enterprise-Niveau“ sind verbreitet, helfen bei einer Kapazitätsplanung jedoch kaum.
Um belastbare Zahlen zu erhalten, haben wir das Verhalten von DecisionRules auf Kubernetes mit Entscheidungstabellen als Testfall gemessen. Alle Angaben in diesem Dokument stammen aus realen Lasttests und nicht aus theoretischen Schätzungen.
Ein kurzer Überblick:
- Eine Regel mittlerer Komplexität wird im Durchschnitt in weniger als 3 Millisekunden gelöst.
- Unter maximaler Last verarbeitet dieselbe Plattform mehr als 100.000 Entscheidungen pro Sekunde bei einer durchschnittlichen Latenz von 10 Millisekunden.
- Durchsatz und Latenz schließen sich bei geeigneter horizontaler Skalierung nicht grundsätzlich aus.
Zusammenfassung der verifizierten Leistungskennzahlen
| Metric | Value | Conditions | |
|---|---|---|---|
| Median latency – decision tables | 2.94 ms | 500 req/s, 3 case avg (small/middle/large) | |
| Median latency – decision trees | 2.59 ms | 500 req/s, 3 case avg | |
| Median latency – script rules | 7.84 ms | 500 req/s, data transformation use case | |
| Median latency – workflows (small) | 3.35 ms | 500 req/s, 3 case avg | |
| Median latency – workflows (medium/large) | 4.98 ms | 500 req/s, 3 case avg | |
| Blended median latency | 3.83 ms | 500 req/s, 13 test cases | |
| Blended p95 latency | 5.29 ms | 500 req/s, 13 test cases | |
| Best case – small decision tree | 1.51 ms | Package-delivery-pricing example | |
| Worst case – script rule p95 | 10.58 ms | Data transformation | |
| Worst case – non-script rule p95 | 9.87 ms | Sequential decision flow |
Was und wie wir getestet haben
- Bereitstellung: Kubernetes-Cluster ohne aktivierte automatische Skalierung
- Region: Lastgeneratoren und Cluster in derselben AWS-Region
- Validierung: Nur Anfragen mit HTTP 200, die zusätzlich die Inhaltsvalidierung bestanden, wurden als erfolgreich gezählt
Getestete Regeltypen:
- Kleine, mittlere und große Entscheidungstabellen
- Scripting Rules zur Datentransformation
- Kleine und große Workflows
- Decision Flows mit 1 bis 10 Regeln pro Ausführung
Alle Anfragen bestanden die Validierung; die Fehlerrate lag bei 0 %.
Unsere Testumgebung
Rohdaten sagen ohne technische Angaben wenig aus. Das waren die Rahmenbedingungen:
Testumgebung
| Application nodes | 3 × c7g.xlarge (4 vCPU, 8 GiB RAM) |
| In-memory cache | Enabled |
| Redis | cache.t4g.micro |
| Load generator | 1 × m7i.2xlarge (K6) |
Die Tests liefen in einer festen AWS-Umgebung mit drei Anwendungsknoten auf Graviton-Instanzen (ARM) und einem zusätzlichen Redis-Knoten. Redis wurde in diesem Test kaum belastet, da der In-Memory-Cache aktiviert war: Die Regeln blieben im Arbeitsspeicher und wurden während der Tests nicht aktualisiert. Sämtliche Tests wurden von einer k6-Instanz in derselben Umgebung ausgeführt, um zusätzliche Störeinflüsse auf die Ergebnisse zu vermeiden.
So nutzen Sie diese Zahlen
Bei der Dimensionierung einer Bereitstellung. Der maximale Durchsatz lag bei mehr als 35.000 Anfragen pro Sekunde und Knoten. Das tatsächliche Ergebnis hängt von den in DecisionRules ausgeführten Regeln und den Leistungsanforderungen Ihrer Anwendung ab. Wir unterstützen Sie gerne bei der passenden Konfiguration und Skalierung.
Bei einer Latenz-SLA. Für alle getesteten Regeln blieb p95 bei 500 Anfragen pro Sekunde unter 10 ms. Dieser Wert lässt sich durch eine an die konkreten Regeln angepasste Konfiguration oder zusätzliche Skalierung optimieren.
Beim Entwurf der Entscheidungslogik. Konsolidieren Sie Aufrufe. Die Ausführung von 10 Regeln innerhalb eines Flows kann nur etwa doppelt so lange dauern wie eine einzelne Regel, weil der Netzwerk-Roundtrip nur einmal anfällt.
Beim Vergleich von Engines. Vergleichen Sie Perzentilverteilungen statt Durchschnittswerte. Ein guter Durchschnitt ist leicht erreichbar, wenn der Idealfall schnell ist. Die Spanne zwischen p50 und p95 zeigt, ob sich Warteschlangen bilden — und genau diese bringen Produktionssysteme an ihre Grenzen.
Geltungsbereich und Einschränkungen
Die Ergebnisse basieren auf einer festen Konfiguration und einer Bereitstellung innerhalb derselben Region. Folgende Punkte sind zu berücksichtigen:
- Payload-Größe: Bei mehr als 10 Millionen Anfragen pro Minute spielt die Datenmenge eine wichtige Rolle.
- Netzwerklatenz ist nicht enthalten: Regionsübergreifende Aufrufe benötigen zusätzliche Zeit.
- Es handelt sich um real gemessene Ergebnisse und nicht um theoretische Höchstwerte.
- Die Werte gelten für den verwendeten Regelsatz und die getestete Umgebung.
Fazit
Diese realen Tests zeigen, dass DecisionRules auf hohen Durchsatz skaliert und dabei eine konstant niedrige Latenz, null Fehler und hohe Zuverlässigkeit bietet.
Ob Sie eine neue Engine bewerten, ein Enterprise-System entwerfen oder Millionen täglicher Entscheidungen planen: Diese Messwerte schaffen Klarheit und Vertrauen für fundierte Entscheidungen.
Ondřej Brejla arbeitet bei DecisionRules, wo er Unternehmen dabei unterstützt, Entscheidungsautomatisierungslösungen zu entwerfen und umzusetzen, die Geschäftsregeln aus hartkodierten Systemen herauslösen und in eine Form bringen, die Fachabteilungen direkt verwalten können. Er konzentriert sich auf Geschäftsregeln, Systemintegrationen und darauf, technischen Teams zu helfen, Prozesse so zu gestalten, dass die Fachanwender Teile der Anwendungen übernehmen können.
