Bonne journée à tous!
Cette année, avec la sortie de Flutter , un cadre pour le développement d'applications multiplateformes, il y a eu une augmentation du battage médiatique dans le langage Dart. Comme tout perfectionniste tergiverser l'ennui paresseux J'ai pensé à comparer les performances de l'implémentation serveur de la machine virtuelle Dart avec son antagoniste potentiel en la personne de Node.js. Je dois dire tout de suite que l'espoir brûlait en moi que Dart gagnerait, et je gagnerais le Saint Graal en me donnant la supériorité sur les concurrents potentiels pour les deux prochaines trois périodes de cinq ans, mais la réalité était un peu différente ...
Boîte à outils
- Machine de test: Core I7, SSD, 12 Go de RAM (aimablement fourni par mon ancien employeur)
- Test de charge: k6.io (au fait, le framework est très intéressant dans son architecture)
Organisation du code d'application
Code source
Ensuite, j'ai surtout décidé de ne pas déranger et j'ai décidé de suivre les recommandations que j'ai lues à un moment donné sur Habré. En particulier:
- Ajout d'une charge utile comme travail de génération de données aléatoires (données aléatoires pour éliminer la mise en cache potentielle des résultats)
class Human { constructor (id, name, surname, age, gender) { this.id = id this.name = name this.surname = surname this.age = age this.gender = gender } }
- Dart et Node.js ont utilisé des options de traitement des demandes synchrones et asynchrones.
- Solutions natives utilisées et solutions sur les frameworks de l'industrie (aqueduc pour dart et express pour node.js)
- Étant donné que l'étude a réussi à obtenir une accélération significative de Dart lors de l'utilisation de l'aqueduc, qui exécute des isolats sur chaque cœur, j'ai utilisé le module de cluster pour node.js pour l'équilibrage
Méthodologie de test
- exécuter des tests de charge avec un nombre donné de requêtes par seconde (500, 750) et une limite sur le nombre d'itérations de test (le nombre de requêtes terminées)
- l'application et le framework de test ont été exécutés sur la même machine, vous devez donc comprendre que tous les résultats sont relatifs et ne peuvent être comparés les uns que les autres
Résultats
Fléchette native
500 rps
750 rps
Cadre d'aqueduc pour Dart
500 rps
750 rps
Nœud.js natif
500 rps
750 rps
Node Express avec cluster
500 rps
750 rps
Conclusions
- Bien sûr, cela dépend beaucoup de la façon dont vous avez implémenté la logique d'application, je ne suis pas vraiment sûr que mon code soit optimal à la fois dans le cas de dart et de node.js
- En particulier, la fonction de génération du tableau pourrait être affichée dans un flux de travail séparé avec une sortie asynchrone, dans mon cas, elle n'a pas été implémentée, par conséquent, l'intégralité de la mosh asynchrone n'a pas été utilisée ici
- Dans Dart et Node.js, la sortie peut être organisée via un flux
- Par conséquent, il reste encore beaucoup de place pour la recherche et l'optimisation des performances.
- Dart dans l'implémentation native des gestionnaires a montré un fichier épique, néanmoins, lorsqu'il est implémenté via le framework, il a montré des résultats impressionnants, selon lesquels la machine virtuelle Dart peut désormais rivaliser avec Node.js
- Pour autant que je sache, une énorme quantité d'heures de travail a été investie dans l'optimisation du V8, je suis plus que sûr que beaucoup moins de temps est investi dans la machine virtuelle Dart. Par conséquent, le second a probablement un potentiel d'optimisation suffisamment grand avant V8