There are some messages that travel back and forth at connect and disconnect as well as whenever a subscription is created. Also there are Keep Alive Messages that are sent so if such a small sample set of actual messages you won't see much difference between tight and loose encoding.
The cache enable option doesn't apply to the .NET client as it doesn't implement this functionality. You can disable the keep alive messages but then you might see connections left open on the broker etc. So use that with caution. Regards On Thu, 2011-08-04 at 07:28 -0700, Phil White wrote: > I'm trying to calculate some approximate messaging bandwidth requirements for > a project which is planning to use ActiveMQ. It's a C#/.NET project so I'm > starting out with an NMS + Openwire assumption. > > I have a test application which publishes topic messages. No text, just some > properties: > IMessage msg = session.CreateMessage(); > msg.NMSType = "WorkflowStateChange"; > msg.Properties["StoryID"] = idStory; > msg.Properties["PreviousState"] = "viewing"; > msg.Properties["NewState"] = "viewed"; > msg.NMSDeliveryMode = MsgDeliveryMode.NonPersistent; > producer.Send(idestWorkflow, msg); > > The test subscriber is running on a virtual machine, and I'm capturing port > 61616 traffic in Wireshark on that VM to allow me to calculate some > approximate bandwidth usage for the project. > > Some findings: > > A) With a connection URI of > "activemq:tcp://HUSH7:61616?wireFormat.tightEncodingEnabled=false" > the above single topic message results in: > 1. A 664 byte packet (612 bytes of application data) from broker->subscriber > 2. A 309 byte packet (255 bytes of application data) from from > subscriber->broker > 3. A 64 byte packet from broker->subscriber > > B) With a connection URI of > "activemq:tcp://HUSH7:61616?wireFormat.tightEncodingEnabled=true&wireFormat.cacheEnabled=true" > the above single topic message results in: > 1. An initial 580 byte packet (526 bytes of application data) from > broker->subscriber > 2. A further sequence of 243 TCP packets (yes, really!) bouncing back and > forth between the subscriber and broker - what on earth are these? > > C) In both above cases all message properties are transported as plain text, > with property names repeated in each successive message, and with lots of 0 > padding. > > So how can I reduce the message overheads? A application data size minimum > of 526 bytes for just 3 or 4 short message properties doesn't seem right, > and I'm hoping there are options to dramatically reduce this size, for > example tokenizing repeated property names or values (I hoped the > cacheEnabled option might do this), packing int/enum properties, or > compressing the whole message. > > I looked into the options for compression (connection.UseCompression=true) > but having hit the problem referred to in > http://activemq.2283324.n4.nabble.com/NMS-Message-Compression-doesn-t-work-because-of-reference-to-specific-Ionic-Zlib-assembly-td3168180.html > this posting I read that compression only applies to the message body, so > not sure it would help with a property-only message like this one. > > I'd be grateful for any advice, or pointers to relevant configuration > options which I've missed. > > Would I see substantial differences using STOMP rather than Openwire? > > Thanks in advance- > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Message-bandwidth-overheads-how-to-reduce-tp3718866p3718866.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. -- Tim Bish ------------ FuseSource Email: tim.b...@fusesource.com Web: http://fusesource.com Twitter: tabish121 Blog: http://timbish.blogspot.com/
