[ https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16598564#comment-16598564 ]
Rob Godfrey commented on QPID-8238: ----------------------------------- In terms of the AMQShortString -> String conversions - would it not make more sense to perhaps look at using java.lang.String values as the keys / values in the FieldTable. It would be interesting perhaps to compare 0-10 performance which uses String and not some other type. > [Broker-J] Improve performance of asynchronous publishing of transient > messages into topic exchange having queues bound using non-overlapping > selectors > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: QPID-8238 > URL: https://issues.apache.org/jira/browse/QPID-8238 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Affects Versions: qpid-java-broker-7.0.6 > Reporter: Alex Rudyy > Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > The performance of asynchronous publishing of transient messages into topic > exchange which routes messages into queues bound using non-overlapping > selectors is 2-3 times slower than performance of 0.32 broker. The > performance degradation is observed with AMQP 0.9, though, I suspect that the > AMQP 0-10 protocol could be affected as well. > I was running tests with 10 concurrent producers publishing messages on > separate connections using the same routing key into 10 different queues > (subscribers queues) bound to the exchange using non-overlapping selectors. > My testing showed that performance of 7.0 broker for this particular use case > was 2-3 times worse than performance of 0.32 broker. > The following factors contributed to degradation of performance: > • Copying data from direct memory into heap memory whilst decoding > message headers. Due to this factor, the decoding of message headers is > around twice slower. It seems it contributes around 70% to total performance > degradation > • The message routing algorithm is slower due to need to support a new > feature to route messages into bound exchanges (in addition to queues) using > replacement routing key. > • AMQ short strings caching contributes 5-10% to total performance > degradation. The caching was added to manage heap space more efficiently. > The numbers provided here could be inaccurate due instrumentation overhead > whilst profiling the issue. > Potentially, caching can be turned off but that will not improve performance > much. > On other hand, adding of additional caching of strings to amqp-short-strings > would improve the performance a bit. Whilst evaluating selectors, the fields > used in selector expressions are represented as java strings but they get > converted every time into amqp-short-strings when looking up for message > header values. If 10 queues are bound to the exchange using the same binding > key, the selector expression is evaluated 10 times for the incoming message. > Thus, all selector field names are get converted into amqp-short-strings 10 > times as well. It seems adding caching here can improve the performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org