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.hi...@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 > >
