Maximisez le débit avec RabbitMQ
Dans notre projet, nous voulons utiliser RabbitMQ dans le modèle "Task Queues" pour transmettre des données.
Du côté du producteur, nous construisons quelques TCP (dans node.js) pour récupérer des données concurrentes élevées et les envoyer à MQ sans rien faire.
Du côté des consommateurs, nous utilisons Java client pour obtenir les données de tâche de MQ, les gérer et ensuite acquitter.
La question est donc la suivante: pour obtenir le débit/les performances maximales de transmission de messages (par exemple, 400 000 msg/seconde), combien de files d'attente est le meilleur? Est-ce que plus de file d'attente signifie un meilleur débit/performances? Et y a-t-il autre chose que je devrais remarquer? Un guide des meilleures pratiques connues pour utiliser RabbitMQ dans un tel scénario?
Tous les commentaires sont très appréciés !!
Pour de meilleures performances dans RabbitMQ, suivez les conseils de ses créateurs. Depuis le blog RabbitMQ :
Les files d'attente de RabbitMQ sont plus rapides lorsqu'elles sont vides . Lorsqu'une file d'attente est vide et que les consommateurs sont prêts à recevoir des messages, dès qu'un message est reçu par la file d'attente, il est directement envoyé au consommateur. Dans le cas d'un message persistant dans une file d'attente durable, oui, il ira également sur le disque, mais cela se fait de manière asynchrone et est fortement tamponné. Le point principal est que très peu de comptabilité doit être effectuée, très peu de structures de données sont modifiées et très peu de mémoire supplémentaire doit être allouée.
Si vous voulez vraiment approfondir les performances des files d'attente RabbitMQ, cette autre entrée de blog la leur va beaucoup plus loin dans les données.
Selon une réponse que j'ai reçue du groupe de diffusion rabbitmq-discuter, il y a d'autres choses que vous pouvez essayer d'augmenter le débit et de réduire la latence:
Utilisez un plus grand nombre de prélecture. Les petites valeurs nuisent aux performances.
Un échange de sujets est plus lent qu'un échange direct ou fanout.
Assurez-vous que les files d'attente restent courtes. Des files d'attente plus longues imposent plus de temps de traitement.
Si vous vous souciez de la latence et des taux de messages, utilisez des messages plus petits. Utilisez un format efficace (par exemple, évitez XML) ou compressez la charge utile.
Expérimentez avec HiPE, ce qui améliore les performances.
Évitez les transactions et la persistance. Évitez également de publier en mode immédiat ou obligatoire. Évitez HA. Le clustering peut également avoir un impact sur les performances.
Vous obtiendrez un meilleur débit sur un système multicœur si vous avez plusieurs files d'attente et consommateurs.
Utilisez au moins la v2.8.1, qui introduit le contrôle de flux. Assurez-vous que les alarmes de mémoire et d'espace disque ne se déclenchent jamais.
La virtualisation peut imposer une petite pénalité de performance.
Réglez votre système d'exploitation et votre pile réseau. Assurez-vous de fournir suffisamment de RAM. Fournit des cœurs rapides et de la RAM.
Vous augmenterez le débit avec un plus grand nombre de prélecture ET en même temps ACK plusieurs messages (au lieu d'envoyer ACK pour chaque message) de votre consommateur.
Mais, bien sûr, ACK avec plusieurs drapeaux sur ( http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.ack ) nécessite une logique supplémentaire sur votre consommateur application ( http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-August/029600.html ). Vous devrez conserver une liste des balises de livraison des messages livrés par le courtier, leur statut (que votre application les ait traités ou non) et ACK chaque N-ème balise de livraison (NDTAG) lorsque tous les messages avec remise -tag inférieur ou égal à NDTAG ont été traités.