Oh well - I tried that but to no avail. I've just dumped the size of our messages (ObjectMessage, so I just serialized the object to a byte[] and took the length - I'm sure it's a bit out, as I imagine there is some overhead for the wire-format - but not by a huge amount) and 98% are > 2K anyway, so I've just set the default messages size in the diagnostic tool to 2k.
Cheers, Charles. -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: 22 June 2006 14:19 To: [email protected] Subject: Re: ThroughPut : Small vs Large Messages Yeah On 6/22/06, Charles Anthony <[EMAIL PROTECTED]> wrote: > Thanks - would that be the TCP_NODELAY jobby ? > > -----Original Message----- > From: James Strachan [mailto:[EMAIL PROTECTED] > Sent: 22 June 2006 11:30 > To: [email protected] > Subject: Re: ThroughPut : Small vs Large Messages > > > It could be the Nagler kicking in - i.e. it might take a little while > for the TCP buffers to be flushed to the network for smaller messages. > You can tune TCP to enable/disable waiting for complete tcp buffers > before actually sending it to the network - its a throughput v latency > tradeoff setting. > > On 6/22/06, Charles Anthony <[EMAIL PROTECTED]> wrote: > > Hi, > > > > We use AMQ (4) as the client/server transport in our system. For some of > our > > clients, we host the application at our site, and though connect remotely > > via VPN. Sometimes, we (well, usually they) have trouble setting up the > VPN > > and setting firewall configs etc - so I am just knocking together a little > > noddy diagnostics program - i.e. connect to the AMQ server, create a temp > > queue, create a producer, create a consumer, send and receive a load of > > messages. > > > > All well and good. > > > > I thought I'd go a bit crazy, then, and try and work out message > throughput > > based on message size (i.e. send & reveive A x byte[B] => bytes sent = > A*B, > > bytes-per-second= A*B/num-secs) - not as a real measurement, but more as > > wavy-hand type uide. > > I've turned async send off for this diagnostic thingy, and messages are > sent > > NON_PERSISTENT. > > > > Here's the weird thing. > > > > If send small messages ( < 1300 ish bytes), I am getting roundtrip of > approx > > 200 ms > > If send larger messages ( > 1300 ish bytes - say 2048), I am getting > > roundtip of < 15 ms > > > > > > Is there a reasonable explanation for this ? Maybe compression kicking in > ? > > I'm just a bit befuddled. > > > > Cheers, > > > > Charles. > > > > > > ___________________________________________________________ > > HPD Software Ltd. - Helping Business Finance Business > > Email terms and conditions: www.hpdsoftware.com/disclaimer > > > > > > > > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > > ___________________________________________________________ > HPD Software Ltd. - Helping Business Finance Business > Email terms and conditions: www.hpdsoftware.com/disclaimer > > > -- James ------- http://radio.weblogs.com/0112098/ ___________________________________________________________ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer
