<div dir="ltr">Thanks Simon.<div><br></div><div>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.)</div>
<div><br></div><div>One other key thing I missed to mention: (<a href="http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.3.1/rabbitmq-dotnet-client-3.3.1-user-guide.pdf">http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.3.1/rabbitmq-dotnet-client-3.3.1-user-guide.pdf</a>)</div>
<div><i><font color="#0000ff"><br></font></i></div><div><div><i><font color="#0000ff">There are two styles of interaction available to ModelBase:</font></i></div><div><i><font color="#0000ff">• synchronous, RPC-style interaction, e.g. ExchangeDeclare, BasicGet and BasicConsume.</font></i></div>
<div><i><font color="#0000ff">• asynchronous, event-style interaction, e.g. BasicAck, BasicPublish.</font></i></div></div><div><i><br></i></div><div>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?</div>
<div><br></div><div>(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.</div>
<div><br></div><div>Thanks!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 9, 2014 at 3:45 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 09/05/14 02:19, Arun Rao wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys -<br>
<br>
Producers (.NET clients) are publishing messages to RabbitMQ cluster at<br>
a rate of 800 to 900 messages/sec. At this rate, RabbitMQ response times<br>
to Ack producers goes significantly higher. It takes longer than 500ms<br>
to ack with a delivery-tag, per channel. (Total Connections: 3000+ at<br>
all times.)<br>
</blockquote>
<br></div>
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.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Objective: Reduce RabbitMQ server response time to less than 100ms when<br>
acknowledging messages on each channel. (Please see we are reusing<br>
connections.)<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>

<br>
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?<br>

<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
</font></span></blockquote></div><br></div>