[rabbitmq-discuss] Basic.Acks terribly slow

[Arun Rao]

Thanks Simon.

The messages are non-persistent but the queues are mirrored to exactly one
other node on a 4-node cluster. I was thinking if I created an exchange for
each routing key, rather than use one exchange and then route by routing
key, would that help? (I am not trying work around anything but I wanted to
know if I am overloading one Exchange when I could create multiple
exchanges. I understand that Exchanges are always HA'ed (even when not
specified) in a cluster. Does that mean that routing and acknowledging to
the messages happens out of just one node on a 4-node cluster? How about
Heartbeats? I am not saying this is a bottleneck but I am trying to
understand the functionality.)

One other key thing I missed to mention: (
http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.3.1/rabbitmq-dotnet-client-3.3.1-user-guide.pdf
)

*There are two styles of interaction available to ModelBase:*
*• synchronous, RPC-style interaction, e.g. ExchangeDeclare, BasicGet and
BasicConsume.*
*• asynchronous, event-style interaction, e.g. BasicAck, BasicPublish.*

Is it true that .NET client library considers BasicPublish and BasicAck as
Events (on a tcp connection), meaning it is not holding up any resources?

(BTW, I am not a developer but I Admin RabbitMQ clusters in production.)
The other take away is to allow publish multiple messages and let .NET
client library keep track of the delivery-tag counts from the server.

Thanks!


On Fri, May 9, 2014 at 3:45 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 09/05/14 02:19, Arun Rao wrote:
>
>> Hi guys -
>>
>> Producers (.NET clients) are publishing messages to RabbitMQ cluster at
>> a rate of 800 to 900 messages/sec. At this rate, RabbitMQ response times
>> to Ack producers goes significantly higher. It takes longer than 500ms
>> to ack with a delivery-tag, per channel. (Total Connections: 3000+ at
>> all times.)
>>
>
> Fundamentally latency is likely to go up when you push the server harder;
> when any given piece of work needs to be done the component that needs to
> do it is doing something else that's unlikely to be avoidable.
>
>
>  Objective: Reduce RabbitMQ server response time to less than 100ms when
>> acknowledging messages on each channel. (Please see we are reusing
>> connections.)
>>
>
> You don't say whether the messages are persistent but I would guess from
> the performance numbers you give that they are. In that case you could
> lower latency by moving to an SSD.
>
> But really, if it's a problem that publish confirms are taking 500ms to
> come back then you might have the wrong expectations; RabbitMQ tries to
> optimise for throughput rather than latency when deciding when to send
> confirms.
>
> Is each producer waiting for each confirm to come back before publishing
> the next message? If so I suggest not doing that; allow publishers to have
> multiple outstanding messages and handle confirms as they come in. If you
> are already doing that, why is waiting 500ms a big deal?
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140509/27c3ec6e/attachment.html>