RabbitMQ avec le plugin Web MQTT et Node.js : comparaison des performances et de l'utilisation de la mémoire

Présentation

Dans les applications qui nécessitent une communication de données efficace et en temps réel, deux technologies couramment utilisées sont RabbitMQ avec le plugin Web MQTT et Node.JS (Socket.IO). RabbitMQ avec le plugin Web MQTT permet la communication à l'aide du protocole MQTT sur WebSockets, tandis que Node.JS (Socket.IO) fournit un environnement d'exécution JavaScript qui gère efficacement les événements en temps réel. Cet article compare les performances et l'utilisation de la mémoire de RabbitMQ avec le plugin Web MQTT et Node.JS (Socket.IO), en particulier pour la gestion de 36 événements tels que les notifications, les rechargements de données et la gestion des files d'attente. Il analyse également si cette configuration est optimale ou nécessite des ajustements supplémentaires.

Présentation de RabbitMQ avec le plugin Web MQTT

Qu'est-ce que RabbitMQ avec le plugin Web MQTT ?

RabbitMQ est un courtier de messages qui prend en charge plusieurs protocoles, dont MQTT. Le plugin Web MQTT dans RabbitMQ permet aux clients de communiquer avec le courtier via WebSockets à l'aide du protocole MQTT. Ceci est particulièrement utile pour les applications Web qui nécessitent une communication bidirectionnelle en temps réel, comme les notifications ou la mise en file d'attente de données.

Fonctions clés de RabbitMQ avec le plugin Web MQTT

1. Communication WebSocket : permet aux clients Web d'utiliser MQTT sur WebSockets, permettant une communication directe entre le serveur et les clients du navigateur.
2. Gestion des files d'attente et des sujets : prend en charge les configurations de files d'attente et de sujets pour une gestion efficace du trafic de messages.
3. Messages conservés : stocke le dernier message afin que les clients nouvellement connectés puissent recevoir les dernières informations sans nouvelle demande.
4. Haute évolutivité pour des messages légers : idéal pour les applications envoyant des notifications en temps réel avec une faible latence, comme les rechargements de données et les files d'attente de notifications.

Présentation de Node.JS (Socket.IO)

Qu'est-ce que Node.JS (Socket.IO) ?

Node.JS (Socket.IO) est un environnement d'exécution JavaScript basé sur le moteur V8 de Chrome, conçu pour gérer les opérations d'E/S non bloquantes. Dans ce contexte, server.js est utilisé pour gérer les événements de notification, les rechargements de données et les files d'attente via les protocoles WebSocket ou HTTP, en fonction des exigences de l'application.

Fonctions clés de Node.JS (Socket.IO)

1. E/S non bloquantes : permet de gérer plusieurs requêtes simultanément sans bloquer d'autres opérations, idéal pour les applications basées sur des événements.
2. Architecture basée sur les événements : réduit la consommation de ressources en exécutant du code uniquement lorsque des événements spécifiques se produisent.
3. Communication bidirectionnelle : Node.JS (Socket.IO) est bien adapté aux applications en temps réel qui nécessitent une communication bidirectionnelle continue entre le client et le serveur via WebSocket.
4. Efficacité et réactivité : gère efficacement un grand nombre de connexions basées sur les E/S, telles que la gestion des notifications et des files d'attente.

Défis et limites

RabbitMQ avec plugin Web MQTT

1. Consommation de ressources : RabbitMQ, en particulier avec le plugin Web MQTT, peut consommer beaucoup de mémoire et de CPU pour gérer des volumes de messages élevés. Dans ce test, RabbitMQ a montré une utilisation du processeur d'environ 5,2 %, ce qui est relativement élevé mais raisonnable pour un courtier de messages.
2. Latence sous charge élevée : sous des charges extrêmement élevées, il peut y avoir une légère latence dans la livraison des messages, ce qui peut avoir un impact sur les applications fortement dépendantes des performances en temps réel.
3. Configuration plus complexe : par rapport à Node.JS (Socket.IO), RabbitMQ avec le plug-in Web MQTT nécessite une configuration initiale plus importante, en particulier pour la configuration des files d'attente, des sujets et des liaisons.

Node.JS (Socket.IO)

1. Single-Threaded : Node.JS (Socket.IO) utilise un seul thread, donc les opérations gourmandes en CPU peuvent devenir un goulot d'étranglement. Lors des tests, l'utilisation du processeur a atteint 50,5 %, ce qui est élevé pour une application monothread et peut entraîner des retards.
2. Fuites de mémoire : si elle n'est pas gérée correctement, une application Node.JS (Socket.IO) peut subir des fuites de mémoire, en particulier dans les applications de longue durée avec une activité événementielle élevée.
3. Dépendance à l'égard de bibliothèques externes : Node.JS (Socket.IO) s'appuie souvent sur de nombreuses bibliothèques tierces qui, si elles ne sont pas maintenues, pourraient affecter les performances globales.

Analyse des performances avec Glances

Aperçu des processus

• RabbitMQ avec le plugin Web MQTT :
  • Utilisation du processeur : 5,2 %
  • Utilisation de la mémoire : 2,8 % (5,97 Go virtuel, 887 Mo résidents)
  • Temps de disponibilité : 18 heures et 26 minutes
• Node.js (serveur.js) :
  • Utilisation du processeur : 50,5 %
  • Utilisation de la mémoire : 0,4 % (1,04 Go virtuel, 257 Mo résidents)
  • Temps de disponibilité : 4 heures et 1 minute

Ces chiffres donnent une première impression de la façon dont chaque service consomme des ressources.

Comparaison de l'utilisation du processeur

• RabbitMQ est relativement léger en CPU, ne consommant que 5,2%, même s'il gère 38 événements (notifications, rechargements de données et tâches de gestion de files d'attente). Cette faible utilisation du processeur est caractéristique de RabbitMQ, car il est optimisé pour la gestion des messages et la communication asynchrone.
• Node.js (server.js) consomme beaucoup plus de CPU, à 50,5 %. Cette utilisation élevée suggère que server.js peut gérer des tâches plus gourmandes en calcul, éventuellement liées à la gestion des connexions WebSocket, au traitement des requêtes ou à la gestion des données en temps réel. Cette utilisation élevée du processeur pourrait avoir un impact sur les performances du serveur sous une charge plus élevée ou lorsque des applications supplémentaires s'exécutent simultanément.

Comparaison de l'utilisation de la mémoire

• RabbitMQ affiche une utilisation de la mémoire plus élevée avec 887 Mo de mémoire résidente, ce qui est raisonnable pour un courtier de messagerie gérant les connexions WebSocket continues et la messagerie MQTT via le plugin Web MQTT. Son empreinte de mémoire virtuelle (5,97 Go) est élevée, mais cela est généralement dû à la pré-allocation et non à la mémoire réellement utilisée.
• Node.js (server.js) a une empreinte mémoire beaucoup plus faible, avec seulement 257 Mo de mémoire résidente. Les applications Node.js ont généralement une faible empreinte mémoire mais peuvent croître en fonction de la complexité des tâches. Son utilisation relativement faible de la mémoire suggère qu'il est bien optimisé pour la gestion des tâches, bien que l'utilisation élevée du processeur puisse indiquer certaines inefficacités dans les tâches liées au processeur.

Disponibilité et stabilité

• RabbitMQ a une disponibilité de plus de 18 heures et utilise un minimum de processeur, ce qui indique qu'il est stable et efficace sur de longues périodes.
• Node.js (server.js) ne fonctionne que depuis 4 heures mais consomme un pourcentage important du CPU. Si cette tendance à l'utilisation du processeur se poursuit, elle pourrait devenir un goulot d'étranglement et nécessiter un redémarrage ou une optimisation, en particulier pour un environnement de production qui s'attend à une disponibilité élevée.

Implications sur les performances du système

• RabbitMQ avec le plugin Web MQTT semble être moins exigeant sur le processeur et modéré en termes d'utilisation de la mémoire. Cela le rend bien adapté aux applications nécessitant une messagerie à haut débit avec une latence minimale. L'utilisation actuelle des ressources ne semble pas excessive, mais il est conseillé de surveiller la mémoire sur des périodes de disponibilité plus longues, car les courtiers de messages peuvent accumuler l'utilisation de la mémoire avec un volume élevé de messages persistants.
• Node.js (server.js) à 50,5 % d'utilisation du processeur suggère qu'il pourrait être lié au processeur, ce qui pourrait affecter d'autres processus ou réduire la réactivité du système sous une charge élevée. Si server.js gère les connexions WebSocket, l'optimisation du code pour les tâches asynchrones ou le déchargement de certains processus pourraient réduire l'utilisation du processeur. Une utilisation élevée du processeur dans Node.js peut également suggérer la nécessité d'un équilibrage de charge sur plusieurs instances, en particulier si le serveur doit évoluer pour gérer davantage d'événements.

Recommandations d'optimisation

• RabbitMQ : bien que l'utilisation de la mémoire de RabbitMQ soit modérée, une surveillance est recommandée pour garantir qu'elle n'augmente pas de manière illimitée au fil du temps, en particulier avec l'augmentation des volumes d'événements.
• Node.js (serveur.js) :
  • Optimiser l'utilisation du processeur : examinez le code pour toute opération gourmande en ressources processeur ou code synchrone qui pourrait bénéficier d'une gestion asynchrone.
  • Benchmark et test de charge : effectuez des tests de résistance pour voir si l'utilisation du processeur de server.js augmente encore avec davantage d'événements simultanés. Cela pourrait aider à identifier des goulots d'étranglement spécifiques au code.
  • Mise à l'échelle : envisagez une mise à l'échelle horizontale pour server.js en exécutant plusieurs instances derrière un équilibreur de charge, en particulier si une utilisation élevée du processeur persiste sous des charges de travail typiques.

Latence

• RabbitMQ avec plug-in Web MQTT : a généralement une faible latence, en particulier dans les communications en temps réel pour les messages légers, ce qui est idéal pour les scénarios de notification et de rechargement de données.
• Node.JS (Socket.IO) : une faible latence, mais une charge CPU élevée peut introduire des retards, surtout si l'application gère des événements gourmands en CPU.

Conclusion

RabbitMQ avec Web MQTT Plugin est un bon choix pour les applications qui nécessitent une gestion des messages en temps réel, en particulier pour les 36 événements, notamment les notifications, les rechargements de données et la gestion des files d'attente. Avec environ 5,2 % d'utilisation du processeur, RabbitMQ est stable pour les charges de transmission de messages élevées, en particulier lorsqu'une faible latence et une communication bidirectionnelle sont nécessaires.

Node.JS (Socket.IO) convient aux applications nécessitant une architecture événementielle avec une communication bidirectionnelle. Cependant, avec une utilisation du processeur atteignant 50,5 %, les applications peuvent être confrontées à des limitations dans les scénarios nécessitant un traitement CPU élevé. Par conséquent, des solutions telles que le clustering ou les threads de travail pourraient être envisagées si l'utilisation continue de croître.

Global :

• RabbitMQ avec plug-in Web MQTT : Fortement recommandé pour les applications ayant des besoins importants en matière de messagerie et de notification. Cela simplifie également la gestion efficace des connexions et des messages via WebSockets.
• Node.JS (Socket.IO) : idéal pour les applications Web qui nécessitent des réponses rapides et une communication bidirectionnelle, mais peuvent nécessiter des ajustements supplémentaires pour réduire la charge du processeur.

Grâce à l'analyse des performances via Glances, les deux technologies ont démontré des résultats en capturant les valeurs d'utilisation du processeur les plus élevées de chaque processus, ce qui est tout à fait approprié pour ce scénario. Cependant, une surveillance régulière est nécessaire pour éviter les pics d'utilisation du processeur ou de la mémoire qui pourraient avoir un impact sur les performances globales du système.

veuillez me corriger si je me trompe ?

Remarque : Si vous avez des suggestions de tests, veuillez commenter ci-dessous et n'hésitez pas à recommander d'autres outils pour la communication en temps réel entre le client et le serveur ?.

Documentation :
https://www.rabbitmq.com/docs/web-mqtt
https://socket.io/docs/v4/

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!