activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Network bridge throughput capped at default Socket buffer size
Date Thu, 21 May 2015 00:45:11 GMT
Peter, I'm pretty sure that's why he's trying to adjust the socket buffer
size, and he's saying that the changes he's making aren't having the
desired effect.

Leung, I have a vague memory having to prefix the URI option with some
prefix (I'm pretty sure it was "transport.", as shown in the example at the
bottom of http://activemq.apache.org/tcp-transport-reference.html).  Give
it a try and see if that changes the behavior you're seeing.

Tim
On May 20, 2015 2:03 PM, "Peter Hicks" <peter.hicks@poggs.co.uk> wrote:

> Hello
>
> On 19/05/15 11:49, Leung Wang Hei wrote:
>
>> There seems to be an invisible barrier in the socket buffer for MQ network
>> bridge.  We expect increasing tcp socket buffer size would give high
>> throughput but the outcome is not.  Here are the test details:
>>
>> - 2 brokers(A, B) bridged together over WLAN with 140ms network latency.
>> - One single duplex network connector is setup at broker B, statically
>> includes one topic
>> - 10 producers each sending 10K message.  All are AMQObjectMessage.
>> - Socket buffer size set as url argument in network connector at broker B
>> and transport connector at broker A
>> - Use wireshark to capture link traffic
>>
>> Wireshark capture shows that throughput always capped at around
>> 3.74Mbit/sec, the max throughput as with default 64K socket buffer.
>> Attached
>> the config details.
>>
>> I don't expect a bug in MQ, am I missing something?  Any advice would be
>> greatly appreciated.
>>
>>  It't not a bug in ActiveMQ, it's the result of the Bandwidth/Delay
> Product - take the bandwidth of your link in megabits/sec and divide it by
> the round trip time in milliseconds.
>
> See http://en.wikipedia.org/wiki/TCP_tuning for more details - you need
> to increase the TCP window size at both broker A and broker B to something
> larger so you can have more data "on the wire".
>
>
> Peter
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message