[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611738#comment-16611738
]
Keith Wall commented on QPID-8238:
----------------------------------
Hi Alex
I think separating the work in separate JIRAs would help.
I would have thought an immutable {{FieldTable}} implementations would be less
code, so should be simpler to reason about and review for correctness, but I
have not tried it.
With BasicContentHeaderProperties, it is not the replacement of AMQShortString
with String that I think would help, I was actually pondering whether decoding
on the short-string fields could be made on demand. For many use-cases (those
without selectors, message user-id validation is off) the the Broker does not
need messageId/correlationId/type/userId etc, so any effort put into decoding
these strings is for nought. Admittedly, the short string caching it already
has should already be preventing most of the waste. I think any change here
should be separated.
Ok, so I understand that the Exchange changes should be just a refactoring
with no functional changes. I'll try to have a quick look.
> [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, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
