[rabbitmq-discuss] detecting publish failure across restart
Jesse Myers
jesse at wavemarket.com
Tue Jun 1 19:55:33 BST 2010
Likewise, I appreciate the feedback.
Can someone elaborate on the expected bottlenecks when using
transactions? From what I've mocked up so far, it looks like the
majority of the overhead is associated with tx.commit (no surprise
there) and that I can get much better performance by batching messages
within a single transaction. I also looked at running multiple tx.commit
operations concurrently in different channels in different threads, but
there doesn't actually appear to be any performance benefit to doing so.
Am I right to conclude that only a single transaction is allowed at a
time per connection?
If so, this suggests queuing up messages client side and having a single
worker thread submit messages in batches. Does this sound reasonable?
Thanks,
Jesse
On 6/1/10 4:35 AM, Sylvain Hellegouarch wrote:
>
>
> On Mon, May 31, 2010 at 10:30 PM, David Wragg <david at rabbitmq.com
> <mailto:david at rabbitmq.com>> wrote:
>
> Hi Sylvain,
>
> Sylvain Hellegouarch <sh at defuze.org <mailto:sh at defuze.org>> writes:
> > I'm curious, in the general case, what's the cost of using a
> transaction?
> > Does it consume more resources? Roughly, what takes place within
> > RabbitMQ?
>
> There is indeed a cost associated with a transaction. One source of
> overhead is the fact that the AMQP tx.commit method is
> synchronous, and
> so involves a round-trip over the network to the server. Another
> is the
> fact that when the server commits a transaction, it must make sure
> that
> the relevant effects of a transaction have reached stable storage
> (e.g. that a persistent message that reaches a queue has been
> stored on
> disk). My colleagues might be able to list other costs.
>
> It's difficult to quantify these costs in general, but I think its
> fair
> to say that they have a significant impact compared with
> non-transactional uses of AMQP. The MulticastMain tool included with
> our Java client library has command line options that allow the impact
> to be measured in various scenarios.
>
> David
>
>
> Cheers for that feedback. Much appreciated. I will try to perform some
> measurements and see both the server and client behave.
>
>
> --
> - Sylvain
> http://www.defuze.org
> http://twitter.com/lawouach
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100601/f24d17c5/attachment.htm
More information about the rabbitmq-discuss
mailing list