[
https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Roskvist updated ARTEMIS-3198:
------------------------------------
Description:
Add ability to increase concurrency on core bridges. This is useful for
deploying bridges over high latency networks when the message volume is high.
More concurrency allows for increased throughput.
I have run some tests locally, sending 20k messages across a WAN link. Using
the default setting I was able to move all messages from point A to point B in:
2m5s31ms
Adding another bridge, with identical parameters besides the name, the same 20k
messages where moved in: 1min6s14ms
Adding a third means: 33s.19ms
So this is pretty much linear increase in throughput based on the number of
bridges configured for the same destination. This works, but if multiple queues
and destinations are involved the config file gets quite messy. Therefor I
propose the addition of a concurrency property for these bridges, which
basically spawns N amount of bridges behind the scenes instead, keeping the
config file nice and tidy and the messages flying.
Test summary:
20k messages (identical across runs), point A to point B over WAN:
1 bridge : 2m 5s 31ms
2 bridges: 1m 6s 14ms
3 bridges: 33s 19ms
Br,
Anton
was:Add ability to increase concurrency on core bridges. This is useful for
deploying bridges over high latency networks when the message volume is high.
More concurrency allows for increased throughput
> Add ability to increase concurrency on core bridges
> ---------------------------------------------------
>
> Key: ARTEMIS-3198
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3198
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Reporter: Anton Roskvist
> Priority: Minor
>
> Add ability to increase concurrency on core bridges. This is useful for
> deploying bridges over high latency networks when the message volume is high.
> More concurrency allows for increased throughput.
>
> I have run some tests locally, sending 20k messages across a WAN link. Using
> the default setting I was able to move all messages from point A to point B
> in: 2m5s31ms
> Adding another bridge, with identical parameters besides the name, the same
> 20k messages where moved in: 1min6s14ms
> Adding a third means: 33s.19ms
> So this is pretty much linear increase in throughput based on the number of
> bridges configured for the same destination. This works, but if multiple
> queues and destinations are involved the config file gets quite messy.
> Therefor I propose the addition of a concurrency property for these bridges,
> which basically spawns N amount of bridges behind the scenes instead, keeping
> the config file nice and tidy and the messages flying.
> Test summary:
> 20k messages (identical across runs), point A to point B over WAN:
> 1 bridge : 2m 5s 31ms
> 2 bridges: 1m 6s 14ms
> 3 bridges: 33s 19ms
> Br,
> Anton
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
