Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGKR+ECHG1pTdP9S67HC2U2CRBETKjS5hrHaZXSH5zP2OPvk8g@mail.gmail.com>
References: 
 <CAGKR+EASiYmGGR+gKg+skh4BFXCZ1rJVqr398scWi5ArdZ6g-Q@mail.gmail.com>
	<CAKUrXK5PJkbDYEv4wmob6qpLNnyzONGjohgD0viTpof-6Ax_cA@mail.gmail.com>
	<CAGKR+EC4nR7-CODaxoDkC+7iL9erfTxZLvw0Ejec12-UuESjuQ@mail.gmail.com>
	<CAGKR+ECHG1pTdP9S67HC2U2CRBETKjS5hrHaZXSH5zP2OPvk8g@mail.gmail.com>
Date: Wed, 26 Sep 2012 19:40:15 -0400
Message-ID: 
 <CAKUrXK7EKqvuh9D_g=OzH+Cs2LF5q-d1DJt86fzBXQNjdkJQpA@mail.gmail.com>
Subject: Re: aprmemcache question
From: Jeff Trawick <trawick@gmail.com>
To: modules-dev@httpd.apache.org
Cc: dev <dev@apr.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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/