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:
--> 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.
