Autosubscribe is quite slow in larger projects

Here is a benchmarking screenshot from our desktop client which communicates with about 20 different types of micro services.

The autosubscribe feature takes about 80 seconds to complete.

Is there a way that we can significantly reduce that time without loosing the ability to add/remove handlers?

Hi Jonas

Judging by the screenshot it looks like the majority of the time is spent in the actual RabbitMQ client operations as well as in creating the dedicated admin connection. Do you know if this is the actual latency from the client to the broker or are you suspecting any other causes that delay the client operations? Any insights from you would be helpful.

How many times do you actually add and remove handlers? Because technically it would be possible to only run the installers once you actually add or remove handlers as part of your deployment pipeline and then all subsequent starts run with disabled installers.

Another option is to script the topology yourself

A third topic that comes to mind is that you could build a conventional routing topology that uses the XyzNoWait channel methods to declare the topology without waiting for the server to confirm the exchange, binding and queue operations. I’m happy to raise an issue for you if you think this should be an opt-in option and we might consider it in the next maintenance release of RabbitMQ (no promises :wink: )


Thanks for all the feedback. I’ll continue to investigate.