On 05/16/2013 09:36 PM, Robert Seward wrote:
In both environments 0.14 and 0.20 the usage pattern is identical. The
same application code just a different version of QPID in each
environment.
Ok, I can confirm that there does seem to be a problem with synchronous
publish performance on trunk at present (quite likely since 0.20)...
I am using the Python client in both cases. I can provide specific
versions if that is required.
The python code originating the messages is:
self.session = conn.session()
self.sender = self.session.sender( qname )
self.sender.send( Message(msg, durable=True) )
From the Python QPID libraries on my machines, I believe the message
sending is synchronous by default. Also my session is
transactional=False by default according to the standard QPID python
libraries. This means I am sending QPID messages synchronously and NOT
in transactions in both environments.
Synchronously sending each durable message is not a pattern the Qpid c++
broker does particularly well at in general. The details of the disk on
the different machines will be more relevant than the processors and
memory for that.
If you can publish asynchronously, that would certainly improve the
throughput. (Also worth checking when comparing to other brokers whether
or not they are synchronously confirming each message or not).
The messages in question seem small to me. 2000 bytes or so of pickled
Python objects.
If it would be beneficial I can use one of the CPP qpid utilities to
send messages and see if the performance is similar or identical to the
performance observed from Python. Just let me know what you want me to
run and I will do it.
Try qpid-perftest with --durable true and --sync-publish true and false
to see the impact of synchronous publication. (You may want to adjust
the --count for --sync-publish true to make it complete a little quicker).
I like the QPID project and wouldn't want to see its persistent message
delivery performance regress.
Me neither! The problem seems mainly confined to the sync publish case
at present. I'll dig into that and send an update.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
