<HTML>
<HEAD>
<TITLE>Re: [rabbitmq-discuss] ConfirmSelect() overhead</TITLE>
</HEAD>
<BODY>
<FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>Yeah, I was hoping to ensure guaranteed delivery simply, without caching messages for re-publishing, but looks like I’ll have to add a thread and cache for doing this. <BR>
<BR>
Is this the convention? To cache the message with its sequence #, with another thread checking on the cache, attempting republish when Nacks received?<BR>
<BR>
thx<BR>
<BR>
On 5/30/13 2:23 PM, "Matthias Radestock" <<a href="matthias@rabbitmq.com">matthias@rabbitmq.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>Adam,<BR>
<BR>
On 30/05/13 18:12, Adam Morgan wrote:<BR>
> Has anyone else done a test to determine the impact of enabling<BR>
> confirmSelect() on publishing channels with respect to publishing rates?<BR>
> In preliminary testing I have seen slower throughput by a ratio of<BR>
> about 40:1. Is this in line with what others have seen?<BR>
<BR>
How are you using confirms?<BR>
<BR>
If you are waiting for a confirm after every single publish then things<BR>
will go very slow indeed, since you are effectively making publish<BR>
synchronous, taking in the entire round trip and processing latency,<BR>
and, depending on the delivery mode, cost of writing to disk.<BR>
<BR>
So don't do that. Ideally applications should handle confirms<BR>
asynchronously, decoupled from publishing. If that is too hard /<BR>
impractical, at least batch the waiting for confirms, e.g. wait for<BR>
confirms every n messages or n seconds.<BR>
<BR>
Matthias.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>