Existe-t-il une différence de performance entre les connexions en pool ou les canaux dans rabbitmq?

Je suis un débutant avec Rabbitmq (et la programmation) alors désolé à l’avance si cela est évident. Je crée un pool à partager entre les threads qui travaillent dans une queue, mais je ne suis pas sûr de devoir 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 performances à avoir un canal par connexion (en termes de débit accru de la queue)? ou est-il préférable d’utiliser une seule connexion par application et de regrouper plusieurs canaux?

note: comme je met en commun les ressources, 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.

Je l’ai trouvé sur le site Web de rabbitmq, il est en bas, j’ai donc cité la partie correspondante ci-dessous.

La version tl; dr est que vous devriez avoir 1 connexion par application et 1 canal par thread. J’espère que cela pourra aider.

Les liaisons

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

Canaux

Certaines applications nécessitent plusieurs connexions à un courtier AMQP. Cependant, il est indésirable de garder plusieurs connexions TCP ouvertes en même temps car cela consum des ressources système et rend plus difficile la configuration des pare-feu. Les connexions AMQP 0-9-1 sont multiplexées avec des canaux pouvant être considérés comme des “connexions légères partageant 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 partager les canaux entre eux.

La communication sur un canal particulier est complètement 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 déterminer le canal auquel la méthode est destinée (et par conséquent, quel gestionnaire d’événement doit être appelé) .

Il est conseillé de disposer d’un canal par thread, même s’ils sont thread-safe, vous pouvez donc envoyer plusieurs threads via un seul canal. En termes de votre application, je vous suggère de restr avec 1 canal par fil cependant.

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

Ce ne sont que des directives, vous devrez donc faire des tests pour voir ce qui vous convient le mieux.

Ce fil a quelques idées ici et ici .

Malgré toutes ces directives, cet article suggère que cela n’aura probablement pas d’incidence sur les performances en ayant plusieurs connexions. Bien qu’il ne soit pas spécifique qu’il s’agisse du côté client ou du côté serveur (rabbitmq). Avec le seul point, il faudra bien sûr utiliser plus de ressources système avec plus de connexions. Si cela ne pose pas de problème et que vous souhaitez augmenter le débit, il peut être préférable d’avoir plusieurs connexions, car cet article suggère que plusieurs connexions vous permettront d’obtenir davantage de débit. La raison semble être que même s’il existe plusieurs canaux, un seul message traverse la connexion en même temps. Par conséquent, un message volumineux bloque la connexion entière 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. Encore une fois, les ressources sont un problème. Si vous utilisez toute la bande passante avec une seule connexion, l’ajout d’une connexion supplémentaire n’aura aucune augmentation des performances par rapport à deux canaux sur la même connexion. De plus, chaque connexion utilisera davantage de mémoire, de processeur et de descripteur de fichier, mais cela pourrait ne pas être un problème, bien que cela puisse poser problème lors de la mise à l’échelle.

En plus de la réponse acceptée:

Si vous avez un cluster de noeuds RabbitMQ avec un équilibreur de charge à l’avant ou un DNS à courte durée de vie (permettant de se connecter à un noeud de lapin différent à chaque fois), une seule connexion à long terme signifie que Le nœud d’application fonctionne exclusivement avec un seul nœud RabbitMQ. Cela peut conduire à utiliser un noeud RabbitMQ plus lourd que les autres.

L’autre préoccupation mentionnée ci-dessus est que la publication et la consommation bloquent les opérations, ce qui conduit à la mise en queue des messages. Avoir plus de connexions garantira 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 convient d’envisager un petit pool de connexions (en tenant compte des problèmes de ressources soulevés ci-dessus).

Le “un canal par fil” peut être une hypothèse sûre (je dirais que je n’ai pas fait de recherche par moi-même et que je n’ai aucune raison de douter de la documentation :)) mais attention

Si vous utilisez RPC avec la réponse RabbitMQ Direct, vous ne pouvez pas réutiliser le même canal à consumr pour une autre requête RPC. J’ai demandé des détails à ce sujet dans le groupe d’utilisateurs Google et la réponse que j’ai reçue de Michael Klishin (qui semble être activement impliqué dans le développement de RabbitMQ) était que

Direct Reply to n’est pas destiné à être utilisé avec le partage de canal.

J’ai envoyé un e-mail à Pivotal pour mettre à jour sa documentation afin d’expliquer comment fonctionne amq.rabbitmq.reply-to et j’attends toujours une réponse (ou une mise à jour).

Donc, si vous voulez restr fidèle à “un canal par thread”, cela ne fonctionnera pas bien avec Direct reply-to.