[
https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569997&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569997
]
ASF GitHub Bot logged work on ARTEMIS-3198:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Mar/21 20:00
Start Date: 22/Mar/21 20:00
Worklog Time Spent: 10m
Work Description: AntonRoskvist commented on pull request #3509:
URL: https://github.com/apache/activemq-artemis/pull/3509#issuecomment-804354885
> Nice contribution!!
> Just curious, as we have made with ReplicationManager on #3392 probably we
are not correctly filling enough packets to maximize the TCP packet size and
amortize network latencies: have you tried by disabling TCP no delay too?
Thanks,
No I haven't tried that and it looks like a real nice optimization, but for
my use case I am looking to increase the throughput I am currently seeing by
some 10-15 times at least. I will definitely try that out as well though!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 569997)
Time Spent: 50m (was: 40m)
> 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
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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)
