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/
