qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Praveen M <lefthandma...@gmail.com>
Subject Re: What is the memory footprint of an Apache qpid queue?
Date Tue, 08 Nov 2011 21:33:27 GMT
Hi Robbie,
              Thanks for the pointer. Yep, setting tcp_nodelay did fix it.

Thanks,
Praveen

On Tue, Nov 8, 2011 at 12:33 PM, Robbie Gemmell <robbie.gemmell@gmail.com>wrote:

> I took another look at this today so I could guage its impact more
> fully. It appeared to be the default setting used for TCP_NODELAY
> which is causing the sluggish behaviour in this scenario (and a few
> others), and testing today showed changing this got the values down to
> 2-3ms avg on my dev box from 42ms or 83ms (2nd run,1st run
> respectively).
>
> You might have noticed I started a discussion on the dev list relating
> to changing this, but regardless of that outcome you can do so now
> through modifying the value via your connection url by updating it to
> this:
> "amqp://guest:guest@test
> /?brokerlist='tcp://localhost:5672?tcp_nodelay='true''&maxprefetch='1'"
>
> Robbie
>
> On 7 November 2011 23:41, Praveen M <lefthandmagic@gmail.com> wrote:
> > Thanks for the update.
> >
> > I was supposed to mean 40 - 50 ms in my first mail about this issue :P I
> > just realized that I had said 40 seconds instead. :) my bad...
> >
> > anyways, I'm glad that you think this can be improved. Thanks a ton for
> > looking into this.
> >
> > Praveen
> >
> > On Mon, Nov 7, 2011 at 3:25 PM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
> >
> >> I took a look at this and was seeing times in line with what you
> >> observed (higher on one PC, lower on another). After some digging and
> >> making a change based on a resulting hunch, I managed to roughly half
> >> the times I was seeing on the faster machine. A small part of the
> >> reduced times is indeed still spent on the stuff I mentioned below
> >> that I dont think is always required, so hopefully that can be
> >> optimised down the line once the addressing code is rewritten and thus
> >> further reduce the times.
> >>
> >> I'd like to properly investigate the impact of the change I made
> >> before I actually say what it is and then see whether we decide it
> >> goes in as the default or not (you would be able to configure it
> >> either way). I probably wont get to finish looking at it for another
> >> few days, but I thought I'd let you know I have something in mind.
> >>
> >> Robbie
> >>
> >> On 7 November 2011 19:20, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
> >> > On 3 November 2011 01:26, Praveen M <lefthandmagic@gmail.com> wrote:
> >> >> Hi Robbie,
> >> > <snip>
> >> > The order of 40-70ms per queue subscription is what I see.
> >> > </snip>
> >> >
> >> > Ok, thas just a touch better than the 40 seconds you mentioned
> earlier :)
> >> >
> >> > I imagine part of this is related to some often-unecessary address
> >> > resolution the client is currently doing against the broker, which
> >> > hopefully should get fixed during some work Rajith is doing on
> >> > redesigning all that stuff. Even then though, thats still slower than
> >> > I would expect. I'll add it to my list of things to look at.
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project:      http://qpid.apache.org
> >> Use/Interact: mailto:users-subscribe@qpid.apache.org
> >>
> >>
> >
> >
> > --
> > -Praveen
> >
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>


-- 
-Praveen

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message