On 06/18/2014 06:39 PM, Fraser Adams wrote:
On 18/06/14 09:13, Gordon Sim wrote:
On 06/17/2014 10:35 PM, smartdog wrote:
It is the qpid c++ broker. The BDB store is used. Is there a way to
improve
the performance while preserving the persistence?
Can you send messages in batches? I.e. don't make every send synchronous.
A synchronous send will always be a little slower and for the c++
broker if the message is durable there is an added penalty at present
over AMQP 1.0 as the broker doesn't flush the disk immediately (it
doesn't get any explicit indication that the client is not going to
send anything else until it gets back the disposition for the message).
Pavel & Gordon, smartdog's original comment said "sending an undurable
message to a qpid queue takes 1-3ms, while sending a durable message
takes static 1000ms" taking 1 second does seem awfully high even given
the synchronous and flush comments, clearly the message size may be
significant, but I'm guessing if he was sending *really big* messages
he'd have said so it's probably not significant here, so the flush delay
seems plausible.
what determines when the flush occurs?
Over 0-10, the client can explicitly trigger the flush by sending a sync
control (or setting the sync flag on the transfer). There is no such
explicit mechanism in 1.0, so at present the flush happens after a short
timeout on the broker side.
This was discussed in a thread started by Pavel some weeks ago. The
broker would need to be altered to allow it to recognise that a given
message is not part of a batch (e.g. because there is no further data
and no further messages for that queue in the data received). This isn't
a trivial change unfortunately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
