Morphium v6 Performance — MongoDB vs PoppyDB vs InMemory
Mit Morphium v6 haben wir den Connection Pool komplett neu geschrieben, das Messaging-System überarbeitet und PoppyDB als MongoDB-kompatiblen In-Memory-Server dazugebaut. Zeit, ein paar Zahlen auf den Tisch zu legen.
Alle Benchmarks liefen auf einem Mac Studio M2 Ultra gegen MongoDB 8.2.4 (3-Node Replica Set) und PoppyDB (3-Node RS, 1.5 GB Heap pro Node). Die Testsuite hat 879 Tests über 5 Backends.
Randbemerkung: Einer unserer Contributors, Heiko Kopp, hat kürzlich beeindruckende Zahlen aus dem Produktionsbetrieb mit Morphium und GraalVM Native Compilation geteilt — 65% schnellerer Startup, 80-85% weniger Speicher, 99% weniger DB-Fehler. Details in seinem Bericht auf GitHub.
Connection Pool: v5 vs v6
Die größte architektonische Änderung in v6 war der Umstieg von einem globalen Lock auf Per-Host-Locking im Connection Pool. Der alte PooledDriver hatte einen einzigen synchronized-Block um den gesamten Pool — eine langsame Operation auf einem Host blockierte damit Threads, die eine Connection zu einem anderen Host brauchten.
v6 nutzt ConcurrentHashMap mit Per-Host-BlockingQueues. Der Unterschied zeigt sich sofort unter Last:
| Benchmark | v5.1.9 | v6.x | Verbesserung |
|---|---|---|---|
| Parallele Reads (20 Threads × 100 Ops) | 22.869 ops/sec | 31.642 ops/sec | +38% |
| Messaging (500 msgs) | 10 msgs/sec | 21 msgs/sec | +110% |
| Bulk Writes (10K Docs) | 43.544 docs/sec | 38.219 docs/sec | -12%* |
*Die Bulk-Write-Regression wird noch untersucht — hängt vermutlich mit dem neuen Write-Concern-Handling zusammen.
Das Messaging-Ergebnis ist kein Zufall: v5 lief in einen Timeout und empfing nur 345 von 500 Nachrichten. v6 bringt alle 500 problemlos durch.
Messaging: Wo PoppyDB richtig glänzt
Messaging ist der Bereich, wo die Backend-Wahl den größten Unterschied macht. Seit v6 ist Messaging ChangeStream-basiert — die Datenbank pusht neue Nachrichten an die Listener statt zu pollen.
| Backend | Durchsatz | Avg Latenz | vs MongoDB |
|---|---|---|---|
| MongoDB (3-Node RS) | 89 msgs/sec | 11,28 ms | 1x |
| PoppyDB (3-Node RS) | 223 msgs/sec | 4,47 ms | 2,5x schneller |
| InMemory Driver | 281 msgs/sec | 3,56 ms | 3,2x schneller |
PoppyDBs Vorteil kommt von null Disk-I/O bei Writes — die Raft-Replikation zwischen den Nodes ist reines Memory-to-Memory über das Netzwerk. MongoDB muss auf den Journal-Flush warten.
Testsuite-Geschwindigkeit
Wir lassen die gleichen 171 netzwerkfähigen Tests gegen alle vier Backends laufen (MongoDB RS, MongoDB Single, PoppyDB RS, PoppyDB Single) plus 195 InMemory-Tests. Mit unserem parallelisierten CI-Setup ist das Ganze in etwa einer Stunde durch — runter von 5 Stunden bei sequenzieller Ausführung.
PoppyDB RS ist ungefähr doppelt so schnell wie MongoDB RS für die volle Testsuite. Das meiste davon kommt von schnellerem Collection-Anlegen, Index-Aufbau und Drops — kein Disk-I/O. Bei einzelnen Tests, die von Sleeps und Timeouts dominiert werden, verschwindet der Unterschied.
Query-Performance: Indexe machen den Unterschied
Ein Bereich, wo MongoDB klar gewinnt: indizierte Queries.
| Feld | MongoDB | InMemory |
|---|---|---|
| Indiziert (500 $in-Werte) | 5,52 ms | 81,30 ms |
| Nicht indiziert (50 $in-Werte) | 10,39 ms | 16,60 ms |
Der InMemory-Driver hat keine echten Indexe — er macht einen Full-Collection-Scan für jede Query. Bei indizierten Feldern ist MongoDB 15x schneller. Bei nicht indizierten Feldern ist InMemory tatsächlich konkurrenzfähig, weil MongoDBs Collection-Scan mehr Overhead pro Dokument hat.
PoppyDB erbt das Query-Verhalten des InMemory-Drivers, also gilt der gleiche Tradeoff. Für Workloads, die hauptsächlich aus Writes und Messaging bestehen (wie unser Produktionssystem), gewinnt PoppyDB. Für read-heavy, indizierte Workloads schlägt nichts echtes MongoDB.
PoppyDB im Produktionsbetrieb
Unser PoppyDB 3-Node RS läuft auf einem 10 GB RAM / 2 CPU LXC-Container mit 1,5 GB Heap pro Node. Raft-Elections nutzen prioritätsbasierte Leader-Wahl (100/75/50) und sind nach einem Failover in unter 5 Sekunden abgeschlossen. Daten werden alle 300 Sekunden auf Disk gedumpt.
Wir nutzen Morphium-Messaging auch in der Produktion, um Millionen von Dokumenten pro Tag durch ein Job-Orchestrierungssystem zu verarbeiten — aber das ist eine Geschichte für einen anderen Post.