On Fri, 2011-08-05 at 07:02 -0700, Phil White wrote: > Thanks Tim > > I don't think these additional messages are connection/subscribe related > though; I'm pushing 100 messages out of the publisher, one every second, and > see the same sequence between each message. Also the 243 packets come > immediately after the message, whereas I would have expected keep-alives to > been seen in the absence of message traffic, rather than being triggered by > it. Here's a typical packet sequence pulled out of Wireshark: >
You can set transport.useLogging=true on the Uri to have the client dump out exactly what messages are coming and going. That would give a hint as to the difference between tight and loose encoding. > --> The message itself > 23685 99.657686 192.168.1.74 192.168.1.76 TCP 580 61616 > > eisport [PSH, ACK] > Seq=51034 Ack=18744 Win=16987 Len=526 23685 > > --> First set of following small packets > 23686 99.658418 192.168.1.76 192.168.1.74 TCP 58 eisport > > 61616 [PSH, ACK] > Seq=18744 Ack=51560 Win=64483 Len=4 23686 > 23687 99.658530 192.168.1.76 192.168.1.74 TCP 55 eisport > > 61616 [PSH, ACK] > Seq=18748 Ack=51560 Win=64483 Len=1 23687 > 23688 99.658591 192.168.1.76 192.168.1.74 TCP 55 eisport > > 61616 [PSH, ACK] > Seq=18749 Ack=51560 Win=64483 Len=1 23688 > 23689 99.658690 192.168.1.74 192.168.1.76 TCP 60 61616 > > eisport [ACK] > Seq=51560 Ack=18749 Win=16982 Len=0 23689 > ..... > 23928 99.675329 192.168.1.74 192.168.1.76 TCP 60 61616 > > eisport [ACK] > Seq=51560 Ack=18937 Win=16794 Len=0 23928 > > --> Next message > 23929 100.623848 192.168.1.74 192.168.1.76 TCP 580 61616 > > eisport [PSH, > ACK] Seq=51560 Ack=18937 Win=16794 Len=526 23929 > > The second column is the Wireshark time, so the 580 byte message appears at > 99.657686 and the first of the small packets at 99.658418 (a > subscriber->broker packet - I guess "eisport" is Wireshark's attempt to > interpret the ephemeral return port number). > > But as I mentioned these additional mystery packets are *only *seen if > wireFormat.tightEncodingEnabled=true, otherwise the number of packets per > message comes down to 3. > > However my main concern is the message packet size itself rather than the > additional 'chatter'. The minimum message size I've managed to achieve so > far, which is for a type-less, parameter-less, body-less message is 329 > bytes of data (383 bytes on the wire). That seems like a huge overhead when > only sending small status messages comprising a few properties (obviously > less of a concern if the message body runs into many KB or MB). > > Are there any further options for reducing this size ? > > Thanks again - > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Message-bandwidth-overheads-how-to-reduce-tp3718866p3721276.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
