Y a-t-il une différence de performance entre la mise en commun de connexions ou de canaux dans rabbitmq ?

Question

Je suis un débutant avec Rabbitmq (et la programmation) donc désolé d'avance si c'est évident. Je suis en train de créer un pool à partager entre les threads qui travaillent sur une file d'attente mais je ne suis pas sûr si je dois utiliser des connexions ou des canaux dans le pool.

Je sais que j'ai besoin de canaux pour faire le travail réel, mais y a-t-il un avantage en termes de performance à avoir un canal par connexion (en termes de débit plus élevé de la file d'attente) ? ou suis-je mieux d'utiliser une seule connexion par application et de regrouper plusieurs canaux ?

note : comme je mets les ressources en commun, le coût initial n'est pas un facteur, car je sais que les connexions sont plus chères que les canaux. Je suis plus intéressé par le débit.

Answer 1

J'ai trouvé ceci sur le site web de rabbitmq Elle se trouve près du bas de la page et j'ai donc cité la partie pertinente ci-dessous.

La version tl;dr est que vous devriez avoir une connexion par application et un canal par fil. J'espère que cela vous aidera.

Connexions

Les connexions AMQP ont généralement une longue durée de vie. AMQP est un protocole de niveau d'application qui utilise le protocole TCP pour une livraison fiable. Les connexions AMQP utilisent l'authentification et peuvent être protégées par TLS (SSL). Lorsqu'une application n'a plus besoin d'être connectée à un broker AMQP, elle doit devrait fermer gracieusement la connexion AMQP au lieu de fermer brusquement de fermer brusquement la connexion TCP sous-jacente.

Chaînes

Certaines applications ont besoin de connexions multiples à un courtier AMQP. Cependant, il n'est pas souhaitable de garder de nombreuses connexions TCP ouvertes en même temps. ouvertes en même temps, car cela consomme des ressources système et complique la plus difficile de configurer les pare-feu. Les connexions AMQP 0-9-1 sont multiplexées avec des canaux que l'on peut considérer comme des "connexions légères légères qui partagent une seule connexion TCP".

Pour les applications qui utilisent plusieurs threads/processus pour le traitement, il est très courant d'ouvrir un nouveau canal par thread/processus et de ne pas et de ne pas partager les canaux entre eux.

La communication sur un canal particulier est totalement distincte de la communication sur un autre canal, par conséquent, chaque méthode AMQP porte également un numéro de canal que les clients utilisent pour savoir à quel canal la méthode est destinée (et donc, quel gestionnaire d'événement doit être invoqué, par exemple).

Il est conseillé d'avoir 1 canal par thread, même s'ils sont thread safe, donc vous pourriez avoir plusieurs threads envoyant par un canal. En ce qui concerne votre application, je vous suggère de vous en tenir à un canal par thread.

De plus, il est conseillé de n'avoir qu'un seul consommateur par canal.

Il ne s'agit que de lignes directrices. Vous devrez donc faire des essais pour déterminer ce qui vous convient le mieux.

Ce fil de discussion donne un aperçu de la situation ici et ici .

Malgré toutes ces directives ce poste suggère que le fait d'avoir plusieurs connexions n'affectera probablement pas les performances. Bien qu'il ne soit pas précisé s'il s'agit du côté client ou du côté serveur (rabbitmq). Le point important est qu'il utilisera bien sûr plus de ressources système avec plus de connexions. Si ce n'est pas un problème et que vous souhaitez avoir plus de débit, il peut en effet être préférable d'avoir plusieurs connexions. ce poste suggère que des connexions multiples vous permettront d'obtenir un meilleur débit. La raison semble être que même s'il y a plusieurs canaux, un seul message passe par la connexion à la fois. Par conséquent, un message important bloquera toute la connexion ou de nombreux messages sans importance sur un canal peuvent bloquer un message important sur la même connexion mais sur un canal différent. Là encore, les ressources sont un problème. Si vous utilisez toute la bande passante avec une connexion, l'ajout d'une connexion supplémentaire n'augmentera pas les performances par rapport à l'utilisation de deux canaux sur la même connexion. De plus, chaque connexion utilisera plus de mémoire, de processeur et de gestionnaires de fichiers, mais cela ne pose pas de problème, même si cela peut en poser un lors de la mise à l'échelle.

Answer 2

En plus de la réponse acceptée :

Si vous avez un cluster de nœuds RabbitMQ avec soit un équilibreur de charge en amont, soit un DNS à courte durée de vie (permettant de se connecter à un nœud RabbitMQ différent à chaque fois), une connexion unique à longue durée de vie signifierait qu'un nœud d'application travaille exclusivement avec un seul nœud RabbitMQ. Cela peut conduire à ce qu'un nœud RabbitMQ soit plus fortement utilisé que les autres.

L'autre problème mentionné ci-dessus est que la publication et la consommation sont des opérations de blocage, ce qui entraîne la mise en file d'attente des messages. Le fait d'avoir plus de connexions permettra de garantir que 1. le temps de traitement de chaque message ne bloque pas les autres messages 2. les gros messages ne bloquent pas les autres messages.

C'est pourquoi il est utile d'envisager de disposer d'un petit pool de connexions (en gardant à l'esprit les problèmes de ressources soulevés ci-dessus).