[rabbitmq-discuss] Performance Hit when using Federation

[Simon MacMullen]

On 30/01/13 18:18, Eric Cozzi wrote:
> Wouldn't republishing more so affect latency, not throughput? I'd expect
> that the federated brokers should be able to republish the messages
> nearly as quickly as they received them. Sure there is going to be
> processing time to perform the network read, queue and re-send the
> message, but that shouldn't affect 'how many' messages a federated
> broker can send in a second?

That depends. If the broker were not anywhere near 100% CPU then yes 
(maybe - it depends what the slowest link in the chain is). If it were 
close to maxed out then the additional work done could push it over the 
edge.

> One of the use cases that we're look at is being able to make an RPC
> call where the client and server are potentially on disparate,
> non-routable networks. Essentially, there would only be a few gateway
> nodes that would span both networks. We're looking at installing
> RabbitMQ on these gateway nodes, and at other key points in our system.
> Thus, we need to be able to support RPC across several intermediate
> RabbitMQ brokers. Federation seemed a natural fit, but is there
> another/better option? The shovel plugin doesn't look to me like it
> would easily fill our need, if I'm not mistaken.

Shovel would definitely require that you take quite a static approach to 
routing for this stuff.

> As for having a mode where federation optimized speed over reliability,
> that might be interesting to us.

Cool. Well it turned out to be very easy to implement, so that will be 
available in RabbitMQ 3.1.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware