[
https://issues.apache.org/jira/browse/ARTEMIS-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175497#comment-17175497
]
Kasper Kondzielski edited comment on ARTEMIS-2852 at 8/11/20, 12:06 PM:
------------------------------------------------------------------------
I migrated our topology as we discussed (here is the PR with all the changes
[https://github.com/softwaremill/mqperf/pull/47])
What is the easiest way to verify if the cluster has been formed and messages
are being replicated to the slaves? In the past we were checking if the data
directory grows, but that's cumbersome with so many nodes.
Also I would like to verify that having a cluster connection specified with
message-load-balancing set to ON_DEMAND is enough to have service side load
balancing. I found that fragment:
??As demontrated in the clustered queue example, if queues with the same name
are deployed on different nodes of a cluster, ActiveMQ Artemis can be
configured to load balance messages between the nodes on the broker side.??
here:
[https://github.com/apache/activemq-artemis/tree/master/examples/features/clustered/queue-message-redistribution]
, which means that we need to have this queue deployed on all masters. I
wonder if the queue will be deployed on more than one node since we use jms
client to do that with a connectionFactory to which we pass all ip addresses of
nodes. Being more precise, how will a node be chosen to connect to given the
connectionFactory with all the nodes?
Last but not least I found that there is something called "Message
Redistribution", shouldn't we turn it on, to be fair when comparing with kafka
and others?
was (Author: kkondzielski):
I migrated our topology as we discussed (here is the PR with all the changes
[https://github.com/softwaremill/mqperf/pull/47])
What is the easiest way to verify if the cluster has been formed and messages
are being replicated to the slaves? In the past we were checking if the data
directory grows, but that's cumbersome with so many nodes.
Also I would like to verify that having a cluster connection specified with
message-load-balancing set to ON_DEMAND is enough to have service side load
balancing. I found that fragment:
??As demontrated in the clustered queue example, if queues with the same name
are deployed on different nodes of a cluster, ActiveMQ Artemis can be
configured to load balance messages between the nodes on the broker side.??
here:
[https://github.com/apache/activemq-artemis/tree/master/examples/features/clustered/queue-message-redistribution]
, which means that we need to have this queue deployed on all masters. I
wonder if the queue will be deployed on more than one node since we use jms
client to do that with a connectionFactory to which we pass all ip addresses of
nodes. Being more precise, how will be chosen a node to connect given the
connectionFactory with all the nodes?
Last but not least I found that there is something called "Message
Redistribution", shouldn't we turn it on, to be fair when comparing with kafka
and others?
> Huge performance decrease between versions 2.2.0 and 2.13.0
> -----------------------------------------------------------
>
> Key: ARTEMIS-2852
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2852
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Kasper Kondzielski
> Priority: Major
> Attachments: Selection_433.png, Selection_434.png, Selection_440.png,
> Selection_441.png, Selection_451.png
>
>
> Hi,
> Recently, we started to prepare a new revision of our blog-post in which we
> test various implementations of replicated queues. Previous version can be
> found here: [https://softwaremill.com/mqperf/]
> We updated artemis binary to 2.13.0, regenerated configuration file and
> applied all the performance tricks you told us last time. In particular these
> were:
> * the {{Xmx}} java parameter bumped to {{16G (now bumped to 48G)}}
> * in {{broker.xml}}, the {{global-max-size}} setting changed to {{8G (this
> one we forgot to set, but we suspect that it is not the issue)}}
> * {{journal-type}} set to {{MAPPED}}
> * {{journal-datasync}}, {{journal-sync-non-transactional}} and
> {{journal-sync-transactional}} all set to false
> Apart from that we changed machines' type we use to r5.2xlarge ( 8 cores, 64
> GIB memory, Network bandwidth Up to 10 Gbps, Storage bandwidth Up to 4,750
> Mbps) and we decided to always run twice as much receivers as senders.
> From our tests it looks like version 2.13.0 is not scaling as well, with the
> increase of senders and receivers, as version 2.2.0 (previously tested).
> Basically is not scaling at all as the throughput stays almost at the same
> level, while previously it used to grow linearly.
> Here you can find our tests results for both versions:
> [https://docs.google.com/spreadsheets/d/1kr9fzSNLD8bOhMkP7K_4axBQiKel1aJtpxsBCOy9ugU/edit?usp=sharing]
> We are aware that now there is a dedicated page in documentation about
> performance tuning, but we are surprised that same settings as before
> performs much worse.
> Maybe there is an obvious property which we overlooked which should be turned
> on?
> All changes between those versions together with the final configuration can
> be found on this merged PR:
> [https://github.com/softwaremill/mqperf/commit/6bfae489e11a250dc9e6ef59719782f839e8874a]
>
> Charts showing machines' usage in attachments. Memory consumed by artemis
> process didn't exceed ~ 16 GB. Bandwidht and cpu weren't also a bottlenecks.
> p.s. I wanted to ask this question on mailing list/nabble forum first but it
> seems that I don't have permissions to do so even though I registered &
> subscribed. Is that intentional?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
