node.js: Root-Server deutlich langsamer als lokaler Server

    Hallo zusammen,

    wir versuchen aktuell ein etwaiges Performance-Problem zu analysieren, sind uns allerdings unsicher, ob die Hardware-Limits schlicht und ergreifend die Ursache sind.

    Zum Setup:

    - Remote: Netcup RS 1000 G9.5 SE NUE BF23 mit 4x AMD EPYC 7702P auf Debian

    - Lokal: AMD Ryzen 7 5700X3D auf Windows 11

    - beide System sind an denselben MongoDB Atlas M10 Cluster remote verbunden.

    - node.js Version und Code sind identisch.

    Zum Use Case:

    - Es werden Daten eines Kunden aus der MongoDB geladen. Über diese läuft serverseitig eine zusätzliche, typische Decrypt-Funktion nach AES-256-CBC, um jedes Feld (String) zu entschlüsseln.

    - In folgendem Beispiel werden ca. 1600 Objekte mit jeweils ca. 25 Key-Values geladen und teilweise (nicht alle) entschlüsselt. Das sind im Output ca. 1,6 Mb.


    Performance:

    Die Messung erfolgt rein serverseitig via console.time(), ohne Client.

    Code
    Lokaler PC:

"Sun Jul 06 2025 12:33:49 GMT+0200 (Mitteleuropäische Sommerzeit) - Performance on {endpoint} for {user}: 1.415s"

Netcup:

"Sun Jul 06 2025 12:35:55 GMT+0200 (Mitteleuropäische Sommerzeit) - Performance on {endpoint} for {user}: 2.580s"

    Das Delta von ca. 1,1 Sekunden erscheint uns hoch.

    Liegt hier ein Performance-Problem vor, oder ist der AMD EPYC bei der Kalkulation tatsächlich so viel langsamer als mein "Gaming-Ryzen"?

    Vielen Dank für eure Mithilfe.

    Die Ryzen 7 5700X3D CPU hat eine 50% höhere Single-Core Leistung als die EPYC 7702P CPU und du hast 8 Cores / 16 Threads in deinem Computer, aber nur 4 Cores in deiner Root-Server-VM. Das Ergebnis kann also nicht wirklich überraschen.

    NaN

    Danke für deine Rückmeldung. Das hätte ich nicht erwartet, dass die CPU so stark limitiert bei einer einzigen, relativ einfachen Operation. Auch waren zu dieser Zeit kaum Kunden aktiv, die das Ergebnis hätten stark verzerren können.

    Ein Upgrade des Root Servers auf die neuen EPYC 9xxx mit 8 dedizierten Kernen würde vermutlich Besserung bringen?

    Wir hatten zeitweise auch überlegt, die MongoDB lokal auf den Server zu ziehen, aufgrund der horrenden Cloud-Kosten – das wäre aber performancetechnisch dann vermutlich erst recht nicht drin.

    Ich habe die Single-Core-Leistung hervorgehoben, weil NodeJS grundsätzlich nicht multithreaded ist. Die zusätzlichen Cores können sich also bei einem Test mit einer einzelnen Anfrage höchstens um losgelöste Aufgaben kümmern und beeinflussen das Ergebnis wenig. Sonst würde der Vorteil des Ryzen noch viel größer ausfallen. Parallelverarbeitung mit NodeJS ist möglich, aber wahrscheinlich nicht umgesetzt. Sonderlich performant scheint die Software ja nicht zu sein, wenn sie für weniger als 2MB Output länger als eine Sekunde braucht. Wenn die Verarbeitung nicht oft von mehreren Clients parallel genutzt wird, langweilen sich die anderen Cores wahrscheinlich und könnten die Datenbank ohne Einbußen für die NodeJS-Anwendung übernehmen. Schau dir die CPU-Auslastung genauer an, dann weißt du mehr.

    Edited once, last by NaN (July 6, 2025 at 2:17 PM).

    Wie die vorherigen Kommentare schon erwähnten, verwendet NodeJS (Eine Laufzeitumgebung für die Skriptsprache JavaScript) lediglich einen Kern und profitiert von der Leistung eines einzelnen Kerns. Ein Upgrade auf einen neueren RS mit einem EPYC 9xxx könnte hier etwas helfen oder Sie schauen sich die neuere und deutlich performantere Alternative "Bun" an, welches ich auch schon seit längerem bevorzuge. Bun ist soweit mit bereits existierende NodeJS Projekte und dem "npmjs" kompatible, demnach ist ein Wechsel ohne zusätzlichen Einstellungen/Änderungen am Projekt möglich.

    Oft liegt es aber an der Optimierung des eigenen Codes und weniger an der Hardware oder der eventuellen Laufzeitumgebung. Eine erneute Prüfung ob dort Abfragen und/oder Schleifen richtig geschrieben und überhaupt notwendig sind könnte sich als positiv bemerkbar machen.

    Ein offizieller Benchmark auf der Webseite zeigt auch noch mal deutlich wie viel performanter Bun sein kann:
    pasted-from-clipboard.pngpasted-from-clipboard.png

    Hier ist noch ein Benchmark von Nutzern. Hier sieht man auch noch mal schön wie niedrig die Latenz und Auslastung der CPU gegenüber NodeJS und Deno sein kann:

    pasted-from-clipboard.png

    Ich empfehle dennoch das sich eine Person mit Erfahrung sich Ihren Quellcode anschaut und diese wenn möglich optimiert. Zudem sollte es Ihnen möglich sein eine solche Datenbank selbst zu hosten, da wie bereits erwähnt hier nicht von Multithreading profitiert wird und demnach genügend Leistung bzw. Kerne für weitere Aufgaben vorhanden sein sollte.

    sudo unsuspend account

    Vielen Dank für die Gedankenanstöße.

    Ich habe in einem ersten Versuch einmal node.js über mehrere Cluster via pm2 gestartet, und auch "worker_threads" auf die besagte Funktion angewendet, sodass ein Objekt mit bspw. 1600 Einträgen entsprechend der Kerne in "Chunks" aufgeteilt wird. Grundsätzlich müsste das Szenario passen, da keine I/O-Operation vorliegt und node.js die Rechenleistung benötigt, um das Decrypting und ein paar tatsächliche Berechnungen auf diesen Objekten durchzuführen.

    Im ersten Ergebnis war die Performance leider schlechter als im "fork"-Mode und ohne "worker_threads". Dennoch könnte das der richtige Weg sein – vorausgesetzt einer korrekten Anwendung, an der es vermutlich scheitert! ;)


    Auf "Bun" werde ich auch mal einen Blick werfen.

    Gruß