Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 72.14.214.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Pq1G0dWgGHfRpUXbETegf53nLs+b0Mwy+CRsTntzgKsdReauN7yT6LeNd4RPH99uCAFglVCJdYBdd15g1fOeGG8UMsoxznyuBaaVF24lLcU+qpjsANso88gX6w4+SvTwVGlsE5yDF9N+ljaUOHxPtziRGS+77GMibJFOFNNuVVI=
Message-ID: <ec6e67fd0606220330n72548969k82a78dae922e3c2a@mail.gmail.com>
Date: Thu, 22 Jun 2006 12:30:27 +0200
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-users@geronimo.apache.org
Subject: Re: ThroughPut : Small vs Large Messages
In-Reply-To: <6FB083FB72EFD21181D30004AC4CA18A0AEA0959@SRV002>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6FB083FB72EFD21181D30004AC4CA18A0AEA0959@SRV002>

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 <charles.anthony@hpdsoftware.com> 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/