J'ai besoin d'un bus de messagerie hautes performances pour mon application. J'évalue donc les performances de ZeroMQ
, RabbitMQ
et Apache Qpid
. Pour mesurer les performances, j'exécute un programme de test qui publie environ 10 000 messages à l'aide de l'une des implémentations de la file d'attente de messages et exécute un autre processus sur le même ordinateur pour utiliser ces 10 000 messages. Ensuite, j’enregistre la différence de temps entre le premier message publié et le dernier message reçu.
Voici les paramètres que j'ai utilisés pour la comparaison.
RabbitMQ
: J'ai utilisé un échange de type "fanout" et une file d'attente avec une configuration par défaut. J'ai utilisé la bibliothèque cliente RabbitMQ C.ZeroMQ
: Mon éditeur publie vers tcp://localhost:port1
avec ZMQ_Push
socket, Mon courtier écoute sur tcp://localhost:port1
et renvoie le message à tcp: // localhost: port2 et mon consommateur écoute sur tcp://localhost:port2
à l'aide de ZMQ_PULL
. J'utilise un courtier au lieu d'une communication homologue à homologue dans ZeroMQ
pour rendre la comparaison de performances équitable avec d'autres implémentations de file d'attente de messages utilisant des courtiers.Qpid
Courtier de messages C++: j'ai utilisé un échange de type "fanout" et une file d'attente avec une configuration par défaut. J'ai utilisé la bibliothèque client Qpid C++.Voici le résultat de la performance:
RabbitMQ
: il faut environ 1 seconde pour recevoir 10 000 messages.ZeroMQ
: Il faut environ 15 millisecondes pour recevoir 10 000 messages.Qpid
: Il faut environ 4 secondes pour recevoir 10 000 messages.Des questions:
RabbitMQ
ou Qpid
pour améliorer ses performances? Remarque:
Les tests ont été effectués sur une machine virtuelle avec deux processeurs alloués. Le résultat peut varier d'un matériel à l'autre, mais je m'intéresse surtout aux performances relatives des produits MQ.
RabbitMQ est probablement en train de persister sur ces messages. Je pense que vous devez définir la priorité du message ou une autre option dans les messages pour éviter la persistance. Les performances s'amélioreront 10x ensuite. Vous devez vous attendre à au moins 100 000 messages/seconde par l'intermédiaire d'un courtier AMQP. Sous OpenAMQ, les performances atteignaient 300 000 messages/seconde.
AMQP était conçu pour la vitesse (par exemple, il ne décompresse pas les messages afin de les acheminer), mais ZeroMQ est simplement mieux conçu de manière clé. Par exemple. il supprime un saut en connectant des nœuds sans courtier; il produit une meilleure E/S asynchrone que n'importe quelle pile de clients AMQP; le traitement des messages est plus agressif. Environ 60% du temps passé à la construction de ZeroMQ a été consacré au réglage des performances. C'était un travail très dur. Ce n'est pas plus rapide par accident.
Une chose que j'aimerais faire, mais je suis trop occupé, est de recréer un courtier de type AMQP en plus de ZeroMQ. Il existe une première couche ici: http://rfc.zeromq.org/spec:15 . L'ensemble de la pile fonctionnerait un peu comme RestMS, le transport et la sémantique étant séparés en deux couches. Il fournirait sensiblement les mêmes fonctionnalités que AMQP/0.9.1 (et serait sémantiquement interopérable) mais beaucoup plus rapidement.
Hmm, bien sûr, ZeroMQ sera plus rapide, il est conçu pour être et n'a pas beaucoup de fonctionnalités basées sur les courtiers que les deux autres fournissent. Le site ZeroMQ présente une merveilleuse comparaison entre messagerie sans courtier et inconvénients et avantages des deux.
RabbitMQ et 0MQ se concentrent sur différents aspects de la messagerie. 0MQ met beaucoup plus l'accent sur la façon dont les messages sont transférés sur le réseau. RabbitMQ, quant à lui, se concentre sur la manière dont les messages sont stockés, filtrés et surveillés.
(J'aime aussi le post ci-dessus RabbitMQ car il est aussi question d'utiliser ZeroMQ avec RabbitMQ)
J'essaie donc de dire que vous devez choisir la technologie qui correspond le mieux à vos besoins. Si la seule exigence est la vitesse, ZeroMQ. Mais si vous avez besoin d'autres aspects tels que la persistance des messages, le filtrage, la surveillance, le basculement, etc., vous devez alors commencer à envisager RabbitMQ & Qpid.
J'utilise un courtier au lieu d'une communication homologue à homologue dans ZeroMQ afin de rendre la comparaison des performances équitable avec d'autres implémentations de file d'attente de messages utilisant des courtiers.
Vous ne savez pas pourquoi vous voulez faire cela - si la seule chose qui compte pour vous est la performance, il n'est pas nécessaire de créer un terrain de jeu égal. Si vous ne vous souciez pas de la persistance, du filtrage, etc., alors pourquoi en payer le prix?
Je suis également très réticent à l'idée de faire des tests de performance sur des machines virtuelles - de nombreuses couches supplémentaires peuvent affecter les résultats d'une manière qui n'est pas évidente. (Sauf si vous envisagez d'exécuter le système réel sur des ordinateurs virtuels, bien sûr, auquel cas c'est une méthode très valable).
J'ai testé c ++/qpid
J'ai envoyé 50000 messages par seconde entre deux machines différentes pendant une longue période sans file d'attente.
Je n'ai pas utilisé de fanout, mais juste un simple échange (messages non persistants)
Utilisez-vous des messages persistants? Est-ce que vous analysez les messages?
Je suppose que non, puisque 0MQ n'a pas de structure de message.
Si le courtier est principalement inactif, vous n'avez probablement pas configuré la prélecture sur l'expéditeur et le récepteur. C'est très important d'envoyer de nombreux messages.
Nous avons comparé RabbitMQ avec notre file de messages persistants SocketPro ( http://www.udaparts.com/ ) sur le site http://www.udaparts.com/document/articles/fastsocketpro.htm avec tous les codes source. Voici les résultats que nous avons obtenus pour RabbitMQ:
Même mise en file d'attente et retrait de la machine:
"Bonjour le monde" --
En file d'attente: 30000 messages par seconde;
File d'attente: 7 000 messages par seconde.Texte avec 1024 octets -
En file d'attente: 11 000 messages par seconde;
File d'attente: 7 000 messages par seconde.Texte avec 10 * 1024 octets -
En file d'attente: 4000 messages par seconde;
File d'attente: 4000 messages par seconde.
Mise en file d'attente et retrait en file d'attente entre machines avec une bande passante réseau de 100 Mbits/s:
"Bonjour le monde" --
En file d'attente: 28 000 messages par seconde;
En attente: 1900 messages par seconde.Texte avec 1024 octets -
En file d'attente: 8 000 messages par seconde;
Dequeue: 1000 messages par seconde.Texte avec 10 * 1024 octets -
En file d'attente: 800 messages par seconde;
File d'attente: 700 messages par seconde.
Essayez de configurer la prélecture sur l’expéditeur et le récepteur avec une valeur telle que 100. La pré-extraction sur expéditeur ne suffit pas
Nous avons développé un bus de messages open source construit sur ZeroMQ - nous l'avions initialement fait pour remplacer Qpid. C'est une solution totalement sans comparaison, mais elle offre les mêmes fonctionnalités que les solutions proposées par des courtiers.
Notre chiffre global de performances est de 140 000 ms par seconde entre deux machines, mais vous pouvez en voir plus en détail ici: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance