apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <jmara...@google.com>
Subject Re: aprmemcache question
Date Thu, 27 Sep 2012 02:05:13 GMT
RE "failing the build of my module" -- the dominant usage is via
precompiled binaries we supply.  Is there an apr query for determining
whether apr was compiled with threads I could do on startup?

-Josh



On Wed, Sep 26, 2012 at 7:40 PM, Jeff Trawick <trawick@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz <jmarantz@google.com>
> wrote:
> > Looking at source, I see that Jeff's patch, and the 'ttl' parameter in
> > general, is only referenced under '#if APR_HAS_THREADS'.  When I
> > load-tested and found the timeouts, I was testing under Apache 2.2
> Prefork,
> > and thus that patched code is not even compiled, IIUC.
> >
> > However I would still like to know what that parameter is for when
> running
> > under Worker.
> >
> > I think the implication of my source journey is also that if my module
> > instantiates multiple threads under Prefork (which it does), it must call
> > apr_memcache* routines from only one of them.  Is that correct?
>
> APR is usually compiled with thread support even when using the
> prefork MPM.  Check APR_HAS_THREADS in apr.h.
>
> If APR_HAS_THREADS is 0 (very unlikely), you probably want to fail the
> build of your module to avoid having to worry about this.
>
> As far as what the parameter means...  I'll try to look tomorrow if
> nobody replies first.
>
> See apu_version() for the APR-util version.
>
> >
> > -Josh
> >
> >
> > On Wed, Sep 26, 2012 at 7:17 PM, Joshua Marantz <jmarantz@google.com>
> wrote:
> >
> >> +dev (sorry for the duplicate; my first attempt failed due to not being
> a
> >> subscriber).
> >>
> >> Keeping modules-dev on CC if that's appropriate.
> >>
> >> Thanks, Jeff, I was wondering if there was a units issue there.  I'm
> still
> >> wondering if anyone can describe the meaning of that argument in more
> >> detail.  Is that related to my multiget APR_TIMEUP returns?   The phrase
> >> "time to live of client connection" confuses me.  Would it be
> inaccurate to
> >> instead say "the maximum number of seconds apr_memcache is willing to
> wait
> >> for a single operation?  Or does it mean *both*, implying that a fresh
> >> TCP/IP connection is made for every new operation, but will stay alive
> for
> >> only a certain number of seconds.
> >>
> >> I have a practical question about how I release software given this
> >> change.  Our module (mod_pagespeed) is documented to run with Apache 2.2
> >> and Apache 2.4.  It seems like for 2.2 I should probably multiple my
> >> desired argument by a million.  Same with for 2.4.x and earlier, for
> some
> >> value of x.  How should I work this in my code?  Should I query the
> version
> >> number using an apr utility or something and multiply by a million in
> >> certain cases?
> >>
> >> What's the best practice calling this function for module developers?
> >>
> >> -Josh
> >>
> >>
> >> On Wed, Sep 26, 2012 at 6:20 PM, Jeff Trawick <trawick@gmail.com>
> wrote:
> >>
> >>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jmarantz@google.com>
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > I've been having some success with the apr_memcache_* functions.  In
> >>> > load-tests, however, I'm finding a lot of timeouts
> >>> > with apr_memcache_multgetp.  Specifically, the status returned with
> the
> >>> > individual elements is APR_TIMEUP.
> >>> >
> >>> > This leads me to wonder what the significance of the second to last
> arg
> >>> to
> >>> > this function is:
> >>> >
> >>> > apr_memcache_server_create(
> >>> >           pool_, hosts_[i].c_str(), ports_[i],
> >>> >           kDefaultServerMin, kDefaultServerSmax,
> >>> >           thread_limit_, kDefaultServerTtlUs, &server);
> >>> >
> >>> > I have kDefaultServerSmax initialized to 600, as that's the value I
> >>> found
> >>> > in mod_socache_memcache.c   But that seems stingy (if it's really in
> >>> > microseconds).  Should I be giving that a few hundred millis instead?
> >>> >
> >>>
> http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___m_c.html#ga18ddd72bc1ab5edb0a08a8f26f193bd3
> >>> > claims
> >>> > that means "time to live of client connection" but I don't understand
> >>> what
> >>> > that phrase means exactly, or if it relates to the APR_TIMEUP returns
> >>> I've
> >>> > been suffering from.
> >>> >
> >>> > My code is here;
> >>> >
> >>>
> http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/apache/apr_mem_cache.cc
> >>> >
> >>> > -Josh
> >>>
> >>> dev@apr.apache.org is a better place to ask about details of apr
> >>> functions.
> >>>
> >>> Coincidentally, earlier today I committed someone's fix for the
> >>> confusion about the units of ttl:
> >>>
> >>> http://svn.apache.org/viewvc?view=revision&revision=1390530
> >>>
> >>> It is supposed to be in seconds.  Pick up the tiny change to
> >>> apr_memcache.c and see if that helps anything.  You should continue
> >>> this discussion on dev@apr.apache.org.
> >>>
> >>> --
> >>> Born in Roswell... married an alien...
> >>> http://emptyhammock.com/
> >>>
> >>
> >>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>

Mime
View raw message