<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Matthias,</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Thanks for the response, I really appreciate it. I am running 2.8.x. Good points on all the measuring too. I probably wasn't clear enough in my post, but what I was saying was if I remove the confirms piece, and make the queue non-durable, the speed of publishing a single message is < 1 ms. I'm using Ruby and a�rudimentary�AMQP client that doesn't do any buffering.</div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
Coupled with your explanations and a little bit of research, it sounds like publisher confirms is only beneficial when done handled asynchronously. I am trying to publish messages from a Ruby web server. Ruby's threading model is very weak and uses in-process green threads. Because of this, I was trying to avoid running any additional threads to perform the async confirms.</div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
It really sounds like with my implementation, I'm doing what RabbitMQ transactions does with minor overhead because of an additional network call. I don't think I had a great enough understanding of confirms when I started this, it sounds like it's only beneficial over transactions if you can receive the confirms asynchronously. Is that true? Thanks again for your help.</div>
<br><div class="gmail_quote">On Mon, Sep 10, 2012 at 5:36 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Allen,<div class="im"><br>
<br>
On 10/09/12 22:06, Allen Riddle wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am curious what people are seeing in their production deployments<br>
of RabbitMQ using publisher confirms in a cluster of nodes with<br>
durable queues.<br>
</blockquote>
<br></div>
Do you see the same results when running your tests against a single<br>
node instead of a cluster? I suspect so, but would be good to get<br>
confirmation of that.<br>
<br>
Also, I am assuming you are running a recent (2.8.x) version of rabbit, right?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With local benchmarks against a cluster with 2 nodes, I'm<br>
synchronously publishing messages and confirming each, and it takes<br>
roughly 46 ms on average per message.<br>
</blockquote>
<br></div>
You are asking RabbitMQ to confirm that the message has been written to<br>
disk. That requires an fsync. Which is very, very expensive.<br>
<br>
You can amortise that cost by: a) dealing with confirms asynchronously,<br>
rather than waiting for a confirmation after every publish, and b)<br>
publishing on multiple connections/channels, as long as that is<br>
compatible with the message ordering guarantees your app requires.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I take away the publisher confirms piece, it falls down to 8 ms,<br>
</blockquote>
<br></div>
Be careful what you are measuring here. If you don't wait for confirms then publishing is an entirely asynchronous operation, so if you are simply timing the duration of the 'publish' API call then you may just be timing how long it takes for the client API to stuff the message into a local buffer.<br>
<br>
Anyway, taking away confirms means that the client won't have to wait for a round trip to the server, and the fsync delay there.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and when I remove durable queues, there is a net zero difference.<br>
</blockquote>
<br></div>
Not sure what you mean here. Zero difference compared to what? Making the queues non-durable eliminates the need to wait for an fsync. There's still the roundtrip latency though.<br>
<br>
Regards,<br>
<br>
Matthias.<br>
</blockquote></div><br>