Replies: 1 comment
-
This is an issue that will be addressed with version 7 of this library. Until then, ensure that your thread pool is large enough to handle all of the parallel operations, or revert to version 5.2 of the library if you were not experiencing any issues with that version. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, after the update to Rabbit MQ Client version 6.4.0 we experience some performance decrease on binding to the queues. The previous version of the RabbitMQ client that we had was 5.2.0.
We have a component (.Net 6.0) that in parallel subscribes to different queues. I can configure the number of workers per queue therefore some queues may have 1 worker while other queues may have multiple workers. All workers are sharing the same RabbitMQ connection (this is created during startup and then cached and provisioned to the workers) and each worker creates a new channel so that in the end we have a channel-per-thread implementation. The workers are long-lived. Basically, they are active as long as the application is running.
This code gets executed when a worker subscribes to a channel.
We experienced slower executions of channel.QueueBind when using RabbitMQ Client version 6.4.0 compared to 5.2.0. These are the average times for channel.QueueBind for approximately 200 queues (with more or less 200 workers in total):
- RabbitMQ Client v5.2.0 - 20-30 ms
- RabbitMQ Client v6.4.0 - 900 - 1000 ms
The Production setup is configured to have around 1000 queues with approximately 1300 workers in total, so the performance implications were more obvious over there.
Do you know if there are known performance issues reported on this topic? Or maybe you see anything strange with this setup?
Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions