Il y a le sentiment que littéralement chaque semaine un nouveau «framework web» pour Node.js apparaît, qui s'appelle quelque chose qui fonctionne plus vite que tout ce qui l'a précédé. Tout le monde sait qu'Express est lent, mais le prochain framework est-il capable d'améliorer vraiment les performances du sous-système d'E / S Node.js? La seule chose qu'il peut faire est d'éliminer la charge excessive sur le système créée par Express. Il n'est pas question d'améliorer quelque chose de fondamental. En fait, afin d'améliorer radicalement la situation, vous devez travailler à un niveau plus profond et ne pas ajouter de nouvelles abstractions au-dessus de Node.js.
Que faut-il pour créer des applications serveur sur la plate-forme Node.js qui fonctionnent beaucoup plus rapidement que tout ce qui existe aujourd'hui?
Analyse de situation
Express est l'un des plus anciens frameworks Web pour Node.js. Il est basé sur les capacités standard de cette plate-forme, offrant aux développeurs une interface pratique construite autour du concept de l'application et vous permettant de gérer les itinéraires, les paramètres, les méthodes et autres URL.
Express est simple; il aide les programmeurs à développer rapidement des applications. La seule chose qui lui manque, c'est la performance. Les projets qui apparaissent constamment, comme Fastify, s'efforcent de donner aux développeurs les mêmes capacités qu'Express, mais avec moins de perte de performances. Mais ce sont eux-mêmes qui créent une charge supplémentaire sur le système et affectent gravement les performances. Ils sont sévèrement limités par ce que la plateforme Node.js. peut fournir. Et cela peut donner, par rapport aux concurrents, pas tant que ça.
Le nombre de requêtes HTTP traitées par différents serveurs par secondeFaites attention à la ligne rouge. Il s'agit de la plateforme maximale Node.js. Pour elle, qu'ils aient ou non le mot «rapide», ils ne sont pas en mesure de franchir cette ligne. Il s'agit en fait d'une limite de performances très faible lors de la comparaison de la plate-forme Node.js avec ses alternatives populaires comme Golang.
Heureusement, Node.js prend en charge les modules complémentaires C ++, les liants Google V8, qui vous permettent de lier JavaScript et C ++, et vous permettent d'appeler tous les mécanismes à partir de JavaScript, même si ces mécanismes sont fournis par autre chose que la plate-forme Node.js.
Cela permet d'étendre et d'améliorer les capacités des applications JavaScript, vous permet d'atteindre de nouveaux niveaux de performances. Cela permet aux programmes JavaScript d'extraire tout ce qui est possible du moteur Google V8, sans se limiter à ce que les développeurs de Node.js ont trouvé tout à fait suffisant.
À propos de µWebSockets.js
Plus tôt ce mois-ci, j'ai publié un nouveau projet -
µWebSockets.js . GitHub est utilisé comme hébergement pour son code, pas npm, mais vous pouvez l'installer pour Node.js en utilisant npm comme ceci:
npm install uNetworking/uWebSockets.js#v15.0.0
Pour travailler avec µWebSockets.js, vous n'avez pas besoin d'un compilateur. Linux, macOS et Windows sont pris en charge. La version initiale du système est 15.0.0, la numérotation des versions est effectuée selon les règles du versioning sémantique.
µWebSockets.js est un serveur Web alternatif pour les applications backend écrites en JS. Il se compose d'environ 6 000 lignes de code C et C ++ et surpasse considérablement les meilleures solutions écrites en Golang. Ainsi, bitfinex.com a déjà porté ses deux API de trading (REST et WebSocket) sur µWebSockets.js et les introduit progressivement en production. Paolo Ardoino de Bitfinex note que c'est un excellent projet. Je voudrais dire que le fait que j'ai eu la possibilité de publier µWebSockets.js est entièrement dû au support fourni par BitMEX, Bitfinex et Coinbase.
Caractéristiques de µWebSockets.js
µWebSockets.js est un nouveau projet publié sous la licence Apache 2.0, qui est une continuation de ce que l'on appelle «uws». Ce projet est une pile complète pour Google V8, commençant au niveau du noyau du système d'exploitation, remplaçant complètement les fonctionnalités standard de Node.js et représentant un sous-système d'E / S stable, sécurisé, conforme aux normes, rapide et léger pour Node.js. Voici à quoi ressemble l'interaction de l'application JS avec le système d'exploitation en utilisant µWebSockets.js.
Interaction de l'application JS avec le système d'exploitation à l'aide de µWebSockets.jsComme vous pouvez le voir, le projet se compose de plusieurs couches. Chaque couche dépend uniquement de la couche précédente. Cette architecture simplifie l'identification et la correction des erreurs, ainsi que la mise en œuvre de travaux pour étendre la solution en raison de la mise en œuvre de nouvelles fonctionnalités en elle.
Il convient de noter que la couche
µSockets elle-même se compose de trois sous-couches, qui sont des mécanismes de travail avec les événements et avec le réseau, ainsi que des outils de protection des données. Cela permet, si nécessaire, de remplacer des parties de la solution, d'ajouter des implémentations alternatives de certaines fonctionnalités au système, sans devoir changer de code à un niveau supérieur.
Par exemple, si vous devez remplacer OpenSSL par quelque chose, remplacez simplement le fichier
ssl.c avec ses six cents lignes de code par ce dont vous avez besoin. Cependant, d'autres couches du système ne savent même pas ce qu'est SSL. Cette approche, en plus de la commodité de remplacer certaines parties du système par d'autres, conduit également à une simplification du processus de détection des erreurs.
OcketsSockets sous-couches internesL'architecture présentée ici est très différente de l'architecture monolithique utilisée dans Node.js, où dans le même fichier de code source, vous pouvez trouver des appels à libuv, des commandes pour travailler avec le système et des appels à OpenSSL et V8. Dans Node.js, tout cela est mélangé, personne n'a cherché à isoler les parties individuelles de cette plate-forme. Cela complique considérablement le processus de modification majeure de Node.js.
À propos du développement de µWebSockets.js
Voici un exemple extrêmement simplifié et raccourci de travail avec µWebSockets.js, dont la tâche principale est de démontrer les capacités de base du système.
uWS.SSLApp({ key_file_name: 'misc/key.pem', cert_file_name: 'misc/cert.pem', passphrase: '1234' }).get('/hello', (res, req) => { res.end('Hello World!'); }).ws('/*', { open: (ws, req) => { console.log('A WebSocket connected via URL: ' + req.getUrl() + '!'); }, message: (ws, message, isBinary) => { let ok = ws.send(message, isBinary); }, drain: (ws) => { console.log('WebSocket backpressure: ' + ws.getBufferedAmount()); }, close: (ws, code, message) => { console.log('WebSocket closed'); } }).listen(port, (token) => { if (token) { console.log('Listening to port ' + port); } });
Dans un sens, nous pouvons dire que µWebSockets.js utilisant SSL peut contourner Gorilla WebSocket, une implémentation du protocole WebSocket sur Go, sans SSL. Autrement dit, il s'avère que le code JS peut échanger des messages en utilisant SSL encore plus rapidement que, sous certaines conditions, le code écrit en Go sans SSL. Je pense que c'est un excellent résultat.
Mise en œuvre rapide du protocole WebSocket
Socket.IO, à bien des égards, peut être considéré comme l'équivalent d'Express en temps réel. Ces deux projets sont apparus il y a longtemps, il est facile de travailler avec eux, ils sont populaires. Mais elles, entre autres, sont également lentes.
Diverses implémentations WebSocketLes tâches que le développeur Socket.IO aide à résoudre sont réduites à la mise en œuvre de la fonctionnalité de publication et d'abonnement des messages, à la capacité d'envoyer et de recevoir des messages.
Dans le même temps, il convient de noter l'utilisation de certains mécanismes de rechange pour travailler avec le protocole WebSocket, car les navigateurs supportent depuis longtemps cette technologie. Le trafic SSL ne peut pas être interprété par les mandataires d'entreprise, il les traverse de la même manière que tout trafic HTTP; par conséquent, l'utilisation du protocole WebSocket sur SSL ne bloque pas le trafic correspondant. Des mécanismes de rechange pour la prise en charge de WebSocket peuvent être fournis, mais il est inutile de les utiliser. Ils ne font qu’accroître déraisonnablement la complexité des décisions.
L'un des objectifs de µWebSockets.js est de donner aux développeurs des fonctionnalités similaires à celles trouvées dans Socket.IO afin que µWebSockets.js puisse remplacer complètement Socket.IO sans avoir besoin de wrappers de niveau supérieur . Cela est possible si aucun protocole spécial non standard n'est utilisé.
De nombreuses entreprises ont des problèmes pour publier et s'abonner aux messages lors de l'utilisation de WebSocket. Il convient de noter que dans la version décrite de µWebSockets.js, ces fonctionnalités n'ont pas reçu beaucoup d'attention, mais un travail sérieux est actuellement en cours. Le résultat sera très rapide (les tests montrent que µWebSockets.js est déjà plus rapide que Redis). Alors restez à l'écoute.
Résumé
Actuellement, µWebSockets.js se développe, de nouvelles fonctionnalités sont ajoutées au projet, des erreurs sont corrigées. Il faudra un certain temps pour se débarrasser de ces défauts mineurs qui sont caractéristiques des premières versions de nouveaux programmes. Gardez à l'esprit qu'il s'agit d'un grand projet composé de plusieurs milliers de lignes de code écrites en C et C ++, qui sont stockées dans trois référentiels.
Ici se trouve le wrapper JavaScript - uWebSockets.js.
Voici un serveur web écrit en C ++ - uWebSockets. Et
voici la bibliothèque de base écrite en C-uSockets.
Le projet en question est utilisé par des entreprises dont les programmes créent une énorme charge sur les sous-systèmes d'E / S. Dans ces entreprises, la stabilité et la sécurité, qui sont tout à fait naturelles et évidentes, sont les caractéristiques les plus importantes du logiciel qu'elles utilisent.
Chers lecteurs! Envisagez-vous d'utiliser µWebSockets.js dans vos projets?
