Guten Tag an alle!
In diesem Jahr hat mit der Veröffentlichung von Flutter , einem Framework für die plattformübergreifende Anwendungsentwicklung, der Hype in der Dart-Sprache zugenommen. Wie jeder Perfektionist zögernde Langeweile faul Ich dachte darüber nach, die Leistung der Serverimplementierung der virtuellen Dart-Maschine mit ihrem potenziellen Antagonisten in der Person von Node.js zu vergleichen. Ich muss sofort sagen, dass die Hoffnung in mir brannte, dass Dart gewinnen würde, und ich würde den heiligen Gral gewinnen, der mir in den nächsten drei Fünfjahresperioden Überlegenheit gegenüber potenziellen Konkurrenten verschafft, aber die Realität sah ein wenig anders aus ...
Toolkit
- Testmaschine: Core I7, SSD, 12 GB RAM (freundlicherweise von meinem früheren Arbeitgeber zur Verfügung gestellt)
- Lasttest: k6.io (das Framework ist übrigens in seiner Architektur sehr interessant)
Organisation des Anwendungscodes
Quellcode
Dann habe ich mich besonders entschlossen, mich nicht darum zu kümmern und den Empfehlungen zu folgen, die ich einmal auf Habré gelesen habe. Insbesondere:
- Es wurde eine Nutzlast hinzugefügt, um zufällige Daten zu generieren (zufällige Daten, um ein mögliches Zwischenspeichern von Ergebnissen zu vermeiden).
class Human { constructor (id, name, surname, age, gender) { this.id = id this.name = name this.surname = surname this.age = age this.gender = gender } }
- Sowohl Dart als auch Node.js verwendeten synchrone und asynchrone Anforderungsverarbeitungsoptionen.
- Verwendete native Lösungen und Lösungen für Branchen-Frameworks (Aquädukt für Dart und Express für node.js)
- Da die Studie bei Verwendung von Aquädukt, das Isolate auf jedem Kern ausführt, eine signifikante Beschleunigung von Dart erzielen konnte, habe ich das Cluster-Modul für node.js zum Ausgleichen verwendet
Testmethode
- Führen Sie Auslastungstests mit einer bestimmten Anzahl von Anforderungen pro Sekunde (500, 750) und einer Begrenzung der Anzahl von Testiterationen (Anzahl der abgeschlossenen Anforderungen) aus.
- Sowohl die Anwendung als auch das Testframework wurden auf demselben Computer ausgeführt. Sie sollten daher verstehen, dass alle Ergebnisse relativ sind und nur miteinander verglichen werden können
Ergebnisse
Einheimischer Pfeil
500 rps
750 rps
Aquädukt-Rahmen für Dart
500 rps
750 rps
Native node.js
500 rps
750 rps
Node Express mit Cluster
500 rps
750 rps
Schlussfolgerungen
- Natürlich hängt vieles davon ab, wie Sie die Anwendungslogik implementiert haben. Ich bin mir nicht sicher, ob mein Code sowohl für dart als auch für node.js optimal ist
- Insbesondere könnte die Funktion zum Generieren des Arrays in einem separaten Worker-Stream mit asynchroner Ausgabe angezeigt werden. In meinem Fall wurde sie nicht implementiert, daher wurde hier nicht der gesamte asynchrone Mosh verwendet
- Sowohl in Dart als auch in Node.js kann die Ausgabe über einen Stream organisiert werden
- Daher gibt es noch viel Raum für Leistungsforschung und Optimierung.
- Dart in der nativen Implementierung von Handlern zeigte eine epische Datei. Bei der Implementierung über das Framework wurden jedoch beeindruckende Ergebnisse erzielt, nach denen die virtuelle Dart-Maschine jetzt mit Node.js konkurrieren kann
- Soweit ich weiß, wurde eine enorme Menge an Arbeitsstunden in die Optimierung des V8 investiert. Ich bin mehr als sicher, dass viel weniger Zeit in die virtuelle Dart-Maschine investiert wird. Daher hat der zweite wahrscheinlich ein ausreichend großes Potenzial für Optimierungen vor V8