qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Why performance of sending durable messages to qpid queue is really bad?
Date Wed, 25 Jun 2014 16:26:37 GMT
On Fri, 2014-06-20 at 12:40 +0100, Gordon Sim wrote:
> On 06/19/2014 10:03 PM, smartdog wrote:
> > I am not sending big messages, just a couple of words. Indeed, I use AMQP
> > 1.0. Then it seems the static 1000ms latency comes from qpid timeout for
> > waiting more messages to write to the store. Can I adjust the timeout value
> > in qpid source code? I would be happy if we could reduce it to 100ms for
> > durable messages.
> The timeout is 500ms by default (at least on trunk at present and I 
> doubt its changed very recently). To edit it change the value for 
> MessageStoreImpl::defJournalFlushTimeout in 
> cpp/src/qpid/legacystore/MessageStoreImpl.cpp
> (There is a timer task per journal, though at present configured to use 
> the same periodicity. So it would be possible without too much work to 
> make it configurable on a per queue basis if anyone had the inclination).

That sounds like an unreasonably large default timeout. Even on cheap
hardware network latency is a few milliseconds and I'm guessing disk
latency is a lot less. A half-second timeout to batch messages from
network to disk sounds completely out of line. Batching for high
throughput is one thing, but imposing such a large artificial latency on
low-throughput applications doesn't make sense.

I would guess that a more appropriate timeout is in the milliseconds or
sub-millisecond range (if it is really necessary at all) but it would
require some performance measurements to determine that.


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message