Die Analyse des Ressourcenverbrauchs wÀhrend der Hochlastphase (bis zu 2.800 EPS Gesamtlast) zeigt die Skalierbarkeit der gewÀhlten Architektur:
FORALL (Bulk-Processing) konnte der Arbeitsspeicherverbrauch pro Session konstant niedrig gehalten werden. Auch bei 4 Mio. DatensÀtzen trat kein Speicherleck auf.Das Test-Szenario hatte drei Ziele:
Das Szenario simulierte somit eine extreme Mischlast (Mixed Workload).
Der Testaufbau bestand aus zwei âPaarenâ von je einem LILAM-Client (Produzent) und einem LILAM-Server (Worker). Im ersten Paar wurden direkt und ohne Unterbrechung Logs, Metriken und StatusĂ€nderungen eines Prozesses gemeldet. Im zweiten Paar wurden von einem Client Messpunkte an einen Server geschickt, deren Zeitstempel unmittelbar davor in eine Tabelle geschrieben wurden. Gleichzeitig arbeitete dieser Server mit einem geladenen Regelsatz (s. Zusammenfassende Bewertung).
REMOTE_LOG, REMOTE_LOG_MON, LILAM_ALERTS).REMOTE_LOG, REMOTE_LOG_MON) + Einzel-Inserts in LATENZ_TEST (indiziert).| Paar | Verarbeitungs-Modus | Durchsatz (EPS) | Status |
|---|---|---|---|
| Paar 1 (Bulk) | FORALL (1000er Batch) |
~1.300 - 1.900 | Stabil ĂŒber 4 Mio. DatensĂ€tze |
| Paar 2 (Latenz) | Row-by-Row |
~460 - 800 | Einbruch bei ~450k (I/O SĂ€ttigung) |
Hinweis: Der Durchsatz von Paar 2 stieg nach Umstellung auf 1.000er Commits um den Faktor 3 an.
Gemessen durch den Zeitstempel-Vergleich zwischen Producer (LATENZ_TEST) und Engine-Eingang (REMOTE_LOG_MON).
| Metrik | Wert (Clean Run 100k) | Wert (Dauerlast 4M) |
|---|---|---|
| Durchschnitt (Avg) | 4,14 ms | ~47.000 ms (Stau-Phase) |
| Maximum (Max) | 2.037,96 ms | > 60.000 ms |
| Jitter (StdDev) | 510,19 | Extrem hoch (CPU SĂ€ttigung) |
Die LILAM-Engine ist im Kern hochperformant (4,14 ms Basis-Latenz). Die Latenzsteigerung unter Dauerlast ist ein rein physikalischer Effekt: Das Notebook-I/O und das 2-Thread-Limit der 21c Free Edition fĂŒhren bei Ăberlastung zur Stau-Bildung in den Pipes. Durch die implementierte Flusssteuerung (Backpressure/Handshake) blieb das Gesamtsystem jedoch zu jeder Zeit konsistent und stabil. Die in
Nach Abschluss der Testreihen wurden die kumulierten Statistik-Werte der Oracle-Instanz ausgewertet. Diese spiegeln die Gesamtbelastung der Hardware nach mehreren DurchlÀufen des Stress-Tests wider.
Die Top-Wartezeiten zeigen die interne Koordination der CPU-Threads bei Hochlast.
| Event Name | Total Waits | Zeit gesamt (Sek.) | Average Wait ms | Ursache |
|---|---|---|---|---|
library cache: mutex X |
282799 | 1.065,85 | 0,04 | CPU-Thread-Limit (Oracle 21c Free) |
library cache pin |
602926 | 488,94 | 0,01 | Gleichzeitiger Zugriff auf PL/SQL Objekte |
resmgr:cpu quantum |
4256 | 623,81 | 1,47 | Drosselung durch Resource Manager |
log file sync |
116 | 2,48 | 0,21 | Warten auf SSD-Quittierung (Commit) |
Physische Last, die durch die 5 Millionen Transaktionen auf dem Notebook-Speicher generiert wurde.
| Metrik | Wert (MB) | Beschreibung |
|---|---|---|
| Redo Size | 4499,18 MB | Gesamtvolumen der generierten Ănderungsprotokolle |
| Physical Writes | 99,1 MB | TatsÀchlich auf die SSD geschriebene Datenmenge |
| Physical Reads | 717,18 MB | Von der SSD gelesene Daten (z.B. fĂŒr Index-Abgleiche) |
Analyse: Ein hohes Redo-Volumen bei gleichzeitig hoher EPS-Rate (2.800+) verdeutlicht die enorme Schreiblast, die das Notebook-I/O bewÀltigen musste.
Zustand des Arbeitsspeichers nach der massiven BefĂŒllung des Library Cache.
| Pool / Name | Wert (MB) | Status |
|---|---|---|
| Shared Pool Total | 563,22 MB | Reserviert fĂŒr SQL & Pipes |
| Free Memory | 136,4 MB | Verbleibende Reserve im Shared Pool |
| Total SGA | 1.129,69 MB | Fest belegter RAM-Block im Notebook |
Die statistische Auswertung zeigt die Performance der Engine wÀhrend eines parallelen Stresstests (1.300 EPS Hintergrundlast).
| Latenz-Klasse | Anzahl Events | Anteil (%) | Bewertung |
|---|---|---|---|
| < 5 ms (Echtzeit) | 52.044 | 52,04 % | System-Basisgeschwindigkeit |
| 5 - 20 ms (Sehr gut) | 1.721 | 1,72 % | Minimale CPU-Wartezeit |
| 20 - 100 ms (Gut) | 10.802 | 10,80 % | Leichte Ressourcen-Konflikte |
| 100 - 500 ms (Verz.) | 20.355 | 20,36 % | 2-Thread Limit (Oracle Free) |
| > 500 ms (Stau/I/O) | 15.078 | 15,08 % | SSD / Redo-Log SĂ€ttigung |
Interpretation der Ergebnisse: Trotz massiver kĂŒnstlicher Ăberlastung durch ein paralleles Producer-Paar verarbeitet die LILAM-Engine ĂŒber 52 % aller Ereignisse in echter Echtzeit (< 5 ms).
Die signifikanten Anteile in den höheren Latenz-Klassen (> 100 ms) sind direkt auf die physikalischen Limitierungen der Testumgebung zurĂŒckzufĂŒhren:
Analyse: WĂ€hrend im unbelasteten Referenzlauf (Clean Run) ĂŒber 95% der Events in unter 10ms verarbeitet wurden, belegt der Mischlast-Test, dass selbst bei extremer Hardware-SĂ€ttigung der GroĂteil der Daten verzögerungsfrei persistiert wird. AusreiĂer korrelieren hierbei exakt mit den physischen Log-Switches der Datenbank.
Zusammenfassende Bewertung:
Die Metriken belegen eine 100%ige Auslastung der Oracle Free Edition. Insbesondere die hohen Werte im Bereich library cache verdeutlichen, dass die Software-Architektur (LILAM) die physikalischen Verwaltungsgrenzen der Datenbank-Instanz erreicht hat. Das System blieb trotz dieser massiven SĂ€ttigung zu jedem Zeitpunkt konsistent.
Die LILAM-Engine weist eine hohe algorithmische Effizienz auf. Validierungstests mit und ohne aktives Regelset (7 Regeln via Assoziativem Array) zeigten identische Durchsatzraten. Dies belegt, dass die logische Verarbeitungsebene im Vergleich zum physikalischen I/O-Durchsatz der Hardware vernachlĂ€ssigbar geringen Overhead erzeugt. Das System ist somit fĂŒr komplexe Regelwerke skalierbar, solange die I/O-KapazitĂ€t der Storage-Anbindung gewahrt bleibt.