You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joshua Marantz <jm...@google.com> on 2012/09/27 01:17:07 UTC
Re: aprmemcache question
+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 <tr...@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
Now that we've established that the TTL passed into the server-create call
is for reaping idle connections and not individual operation timeouts, I
want to ask about timing out individual operations.
If memcached freezes, then it appears my calls to 'get' will block until
memcached wakes up. Is there any way to set a timeout for that call?
I can repro this in my unit tests by sending a SIGSTOP to memcached before
doing a 'get'.
-Josh
On Thu, Sep 27, 2012 at 4:37 PM, Joshua Marantz <jm...@google.com> wrote:
> This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
>
> I need to investigate why some lookups take a second or more. Maybe
> there's a mutex contention on my end somewhere.
>
> Thanks!
> -Josh
>
>
>
> On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com>
>> wrote:
>> > That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
>> > right? That was where I stole my args from.
>>
>> no, subversion
>>
>> > As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
>> > interface, I'm still not clear on exactly what that means. Does a
>> value of
>> > 600 mean that a single multiget must complete in 600 microseconds
>> otherwise
>> > it fails with APR_TIMEUP?
>>
>> ttl only affects connections which are not currently used; it does not
>> control I/O timeouts
>>
>>
>> > That might explain the behavior I saw.
>> >
>> > I've now jacked that up by x1e6 to 600 seconds and I don't see
>> timeouts,
>> > but I'm hoping someone can bridge the gap between the socket-level
>> > explanation and the apr_memcache API call.
>> >
>> > I was assuming that apr_memcache created the TCP/IP connection when I
>> called
>> > apr_memcache_server_create, and there even 600 seconds seems too short.
>> Is
>> > the functionality more like it will create connections on-demand and
>> leave
>> > them running for N microseconds, re-using the connection for multiple
>> > requests until TTL microseconds have elapsed since creation?
>>
>> create on demand
>> reuse existing idle connections when possible
>> when performing maintenance on the idle connections, clean up any
>> which were idle for N microseconds
>>
>> If a connection is always reused before it is idle for N microseconds,
>> it will live as long as memcached allows.
>>
>> > If that's the case then I guess that every 10 minutes one of my cache
>> > lookups may have high latency to re-establish the connection, is that
>> right?
>> > I've been histogramming this under load and seeing some long tail
>> requests
>> > with very high latency. My median latency is only 143us which is great.
>> > My 90%, 95% and 99% are all around 5ms, which is fine as well. But
>> I've got
>> > a fairly significant number of long-tail lookups that take hundreds of
>> ms or
>> > even seconds to finish, and one crazy theory is that this is all
>> reconnect
>> > cost.
>> >
>> > It would be nice if the TTL were interpreted as a maximum idle time
>> before
>> > the connection is reaped, rather than stuttering response-time on a very
>> > active channel.
>>
>> It is. The ttl is interpreted by the reslist layer, which won't touch
>> objects until they're returned to the list.
>>
>> >
>> > This testing is all using a single memcached running on localhost.
>> >
>> > -Josh
>> >
>> >
>> > On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com>
>> wrote:
>> >>
>> >> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
>> >> wrote:
>> >> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
>> >> > wrote:
>> >> >>
>> >> >> If dlsym() is called with the special handle NULL, it is
>> interpreted
>> >> >> as
>> >> >> a
>> >> >> reference to the executable or shared object from which the call
>> is
>> >> >> being
>> >> >> made. Thus a shared object can reference its own symbols.
>> >> >>
>> >> >> And that's how it works on Linux, Solaris, NetBSD and probably
>> OpenBSD
>> >> >> as
>> >> >> well.
>> >> >
>> >> >
>> >> > Cool, thanks.
>> >> >>
>> >> >> > Do you have a feel for the exact meaning of that TTL parameter to
>> >> >> > apr_memcache_server_create?
>> >> >>
>> >> >> You mean what units it uses? Microseconds (at least, in 2.4).
>> >> >
>> >> >
>> >> > Actually what I meant was what that value is used for in the library.
>> >> > The
>> >> > phrase "time to live of client connection" confuses me. Does it
>> really
>> >> > mean
>> >> > "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.
>> >>
>> >> TCP/IP connections, once created, will be retained for the specified
>> >> (ttl) number of seconds. They'll be created when needed.
>> >>
>> >> The socket connect timeout is hard-coded to 1 second, and there's no
>> >> timeout for I/O.
>> >>
>> >> >
>> >> >
>> >> > It is a little disturbing from a module-developer perspective to have
>> >> > the
>> >> > meaning of that parameter change by a factor of 1M between versions.
>> >> > Would
>> >> > it be better to revert the recent change and instead change the doc
>> to
>> >> > match
>> >> > the current behavior?
>> >>
>> >> The doc was already changed to match the behavior, but I missed that.
>> >> The caller I know of used the wrong unit, and I'll submit a patch to
>> >> fix that in the caller, as well as revert my screw-up from yesterday.
>> >>
>> >> >
>> >> > -Josh
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Born in Roswell... married an alien...
>> >> http://emptyhammock.com/
>> >
>> >
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
Now that we've established that the TTL passed into the server-create call
is for reaping idle connections and not individual operation timeouts, I
want to ask about timing out individual operations.
If memcached freezes, then it appears my calls to 'get' will block until
memcached wakes up. Is there any way to set a timeout for that call?
I can repro this in my unit tests by sending a SIGSTOP to memcached before
doing a 'get'.
-Josh
On Thu, Sep 27, 2012 at 4:37 PM, Joshua Marantz <jm...@google.com> wrote:
> This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
>
> I need to investigate why some lookups take a second or more. Maybe
> there's a mutex contention on my end somewhere.
>
> Thanks!
> -Josh
>
>
>
> On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com>
>> wrote:
>> > That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
>> > right? That was where I stole my args from.
>>
>> no, subversion
>>
>> > As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
>> > interface, I'm still not clear on exactly what that means. Does a
>> value of
>> > 600 mean that a single multiget must complete in 600 microseconds
>> otherwise
>> > it fails with APR_TIMEUP?
>>
>> ttl only affects connections which are not currently used; it does not
>> control I/O timeouts
>>
>>
>> > That might explain the behavior I saw.
>> >
>> > I've now jacked that up by x1e6 to 600 seconds and I don't see
>> timeouts,
>> > but I'm hoping someone can bridge the gap between the socket-level
>> > explanation and the apr_memcache API call.
>> >
>> > I was assuming that apr_memcache created the TCP/IP connection when I
>> called
>> > apr_memcache_server_create, and there even 600 seconds seems too short.
>> Is
>> > the functionality more like it will create connections on-demand and
>> leave
>> > them running for N microseconds, re-using the connection for multiple
>> > requests until TTL microseconds have elapsed since creation?
>>
>> create on demand
>> reuse existing idle connections when possible
>> when performing maintenance on the idle connections, clean up any
>> which were idle for N microseconds
>>
>> If a connection is always reused before it is idle for N microseconds,
>> it will live as long as memcached allows.
>>
>> > If that's the case then I guess that every 10 minutes one of my cache
>> > lookups may have high latency to re-establish the connection, is that
>> right?
>> > I've been histogramming this under load and seeing some long tail
>> requests
>> > with very high latency. My median latency is only 143us which is great.
>> > My 90%, 95% and 99% are all around 5ms, which is fine as well. But
>> I've got
>> > a fairly significant number of long-tail lookups that take hundreds of
>> ms or
>> > even seconds to finish, and one crazy theory is that this is all
>> reconnect
>> > cost.
>> >
>> > It would be nice if the TTL were interpreted as a maximum idle time
>> before
>> > the connection is reaped, rather than stuttering response-time on a very
>> > active channel.
>>
>> It is. The ttl is interpreted by the reslist layer, which won't touch
>> objects until they're returned to the list.
>>
>> >
>> > This testing is all using a single memcached running on localhost.
>> >
>> > -Josh
>> >
>> >
>> > On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com>
>> wrote:
>> >>
>> >> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
>> >> wrote:
>> >> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
>> >> > wrote:
>> >> >>
>> >> >> If dlsym() is called with the special handle NULL, it is
>> interpreted
>> >> >> as
>> >> >> a
>> >> >> reference to the executable or shared object from which the call
>> is
>> >> >> being
>> >> >> made. Thus a shared object can reference its own symbols.
>> >> >>
>> >> >> And that's how it works on Linux, Solaris, NetBSD and probably
>> OpenBSD
>> >> >> as
>> >> >> well.
>> >> >
>> >> >
>> >> > Cool, thanks.
>> >> >>
>> >> >> > Do you have a feel for the exact meaning of that TTL parameter to
>> >> >> > apr_memcache_server_create?
>> >> >>
>> >> >> You mean what units it uses? Microseconds (at least, in 2.4).
>> >> >
>> >> >
>> >> > Actually what I meant was what that value is used for in the library.
>> >> > The
>> >> > phrase "time to live of client connection" confuses me. Does it
>> really
>> >> > mean
>> >> > "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.
>> >>
>> >> TCP/IP connections, once created, will be retained for the specified
>> >> (ttl) number of seconds. They'll be created when needed.
>> >>
>> >> The socket connect timeout is hard-coded to 1 second, and there's no
>> >> timeout for I/O.
>> >>
>> >> >
>> >> >
>> >> > It is a little disturbing from a module-developer perspective to have
>> >> > the
>> >> > meaning of that parameter change by a factor of 1M between versions.
>> >> > Would
>> >> > it be better to revert the recent change and instead change the doc
>> to
>> >> > match
>> >> > the current behavior?
>> >>
>> >> The doc was already changed to match the behavior, but I missed that.
>> >> The caller I know of used the wrong unit, and I'll submit a patch to
>> >> fix that in the caller, as well as revert my screw-up from yesterday.
>> >>
>> >> >
>> >> > -Josh
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Born in Roswell... married an alien...
>> >> http://emptyhammock.com/
>> >
>> >
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
I need to investigate why some lookups take a second or more. Maybe
there's a mutex contention on my end somewhere.
Thanks!
-Josh
On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com>
> wrote:
> > That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> > right? That was where I stole my args from.
>
> no, subversion
>
> > As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> > interface, I'm still not clear on exactly what that means. Does a value
> of
> > 600 mean that a single multiget must complete in 600 microseconds
> otherwise
> > it fails with APR_TIMEUP?
>
> ttl only affects connections which are not currently used; it does not
> control I/O timeouts
>
>
> > That might explain the behavior I saw.
> >
> > I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
> > but I'm hoping someone can bridge the gap between the socket-level
> > explanation and the apr_memcache API call.
> >
> > I was assuming that apr_memcache created the TCP/IP connection when I
> called
> > apr_memcache_server_create, and there even 600 seconds seems too short.
> Is
> > the functionality more like it will create connections on-demand and
> leave
> > them running for N microseconds, re-using the connection for multiple
> > requests until TTL microseconds have elapsed since creation?
>
> create on demand
> reuse existing idle connections when possible
> when performing maintenance on the idle connections, clean up any
> which were idle for N microseconds
>
> If a connection is always reused before it is idle for N microseconds,
> it will live as long as memcached allows.
>
> > If that's the case then I guess that every 10 minutes one of my cache
> > lookups may have high latency to re-establish the connection, is that
> right?
> > I've been histogramming this under load and seeing some long tail
> requests
> > with very high latency. My median latency is only 143us which is great.
> > My 90%, 95% and 99% are all around 5ms, which is fine as well. But I've
> got
> > a fairly significant number of long-tail lookups that take hundreds of
> ms or
> > even seconds to finish, and one crazy theory is that this is all
> reconnect
> > cost.
> >
> > It would be nice if the TTL were interpreted as a maximum idle time
> before
> > the connection is reaped, rather than stuttering response-time on a very
> > active channel.
>
> It is. The ttl is interpreted by the reslist layer, which won't touch
> objects until they're returned to the list.
>
> >
> > This testing is all using a single memcached running on localhost.
> >
> > -Josh
> >
> >
> > On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com>
> wrote:
> >>
> >> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
> >> wrote:
> >> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
> >> > wrote:
> >> >>
> >> >> If dlsym() is called with the special handle NULL, it is
> interpreted
> >> >> as
> >> >> a
> >> >> reference to the executable or shared object from which the call is
> >> >> being
> >> >> made. Thus a shared object can reference its own symbols.
> >> >>
> >> >> And that's how it works on Linux, Solaris, NetBSD and probably
> OpenBSD
> >> >> as
> >> >> well.
> >> >
> >> >
> >> > Cool, thanks.
> >> >>
> >> >> > Do you have a feel for the exact meaning of that TTL parameter to
> >> >> > apr_memcache_server_create?
> >> >>
> >> >> You mean what units it uses? Microseconds (at least, in 2.4).
> >> >
> >> >
> >> > Actually what I meant was what that value is used for in the library.
> >> > The
> >> > phrase "time to live of client connection" confuses me. Does it
> really
> >> > mean
> >> > "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.
> >>
> >> TCP/IP connections, once created, will be retained for the specified
> >> (ttl) number of seconds. They'll be created when needed.
> >>
> >> The socket connect timeout is hard-coded to 1 second, and there's no
> >> timeout for I/O.
> >>
> >> >
> >> >
> >> > It is a little disturbing from a module-developer perspective to have
> >> > the
> >> > meaning of that parameter change by a factor of 1M between versions.
> >> > Would
> >> > it be better to revert the recent change and instead change the doc to
> >> > match
> >> > the current behavior?
> >>
> >> The doc was already changed to match the behavior, but I missed that.
> >> The caller I know of used the wrong unit, and I'll submit a patch to
> >> fix that in the caller, as well as revert my screw-up from yesterday.
> >>
> >> >
> >> > -Josh
> >> >
> >>
> >>
> >>
> >> --
> >> Born in Roswell... married an alien...
> >> http://emptyhammock.com/
> >
> >
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
I need to investigate why some lookups take a second or more. Maybe
there's a mutex contention on my end somewhere.
Thanks!
-Josh
On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com>
> wrote:
> > That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> > right? That was where I stole my args from.
>
> no, subversion
>
> > As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> > interface, I'm still not clear on exactly what that means. Does a value
> of
> > 600 mean that a single multiget must complete in 600 microseconds
> otherwise
> > it fails with APR_TIMEUP?
>
> ttl only affects connections which are not currently used; it does not
> control I/O timeouts
>
>
> > That might explain the behavior I saw.
> >
> > I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
> > but I'm hoping someone can bridge the gap between the socket-level
> > explanation and the apr_memcache API call.
> >
> > I was assuming that apr_memcache created the TCP/IP connection when I
> called
> > apr_memcache_server_create, and there even 600 seconds seems too short.
> Is
> > the functionality more like it will create connections on-demand and
> leave
> > them running for N microseconds, re-using the connection for multiple
> > requests until TTL microseconds have elapsed since creation?
>
> create on demand
> reuse existing idle connections when possible
> when performing maintenance on the idle connections, clean up any
> which were idle for N microseconds
>
> If a connection is always reused before it is idle for N microseconds,
> it will live as long as memcached allows.
>
> > If that's the case then I guess that every 10 minutes one of my cache
> > lookups may have high latency to re-establish the connection, is that
> right?
> > I've been histogramming this under load and seeing some long tail
> requests
> > with very high latency. My median latency is only 143us which is great.
> > My 90%, 95% and 99% are all around 5ms, which is fine as well. But I've
> got
> > a fairly significant number of long-tail lookups that take hundreds of
> ms or
> > even seconds to finish, and one crazy theory is that this is all
> reconnect
> > cost.
> >
> > It would be nice if the TTL were interpreted as a maximum idle time
> before
> > the connection is reaped, rather than stuttering response-time on a very
> > active channel.
>
> It is. The ttl is interpreted by the reslist layer, which won't touch
> objects until they're returned to the list.
>
> >
> > This testing is all using a single memcached running on localhost.
> >
> > -Josh
> >
> >
> > On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com>
> wrote:
> >>
> >> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
> >> wrote:
> >> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
> >> > wrote:
> >> >>
> >> >> If dlsym() is called with the special handle NULL, it is
> interpreted
> >> >> as
> >> >> a
> >> >> reference to the executable or shared object from which the call is
> >> >> being
> >> >> made. Thus a shared object can reference its own symbols.
> >> >>
> >> >> And that's how it works on Linux, Solaris, NetBSD and probably
> OpenBSD
> >> >> as
> >> >> well.
> >> >
> >> >
> >> > Cool, thanks.
> >> >>
> >> >> > Do you have a feel for the exact meaning of that TTL parameter to
> >> >> > apr_memcache_server_create?
> >> >>
> >> >> You mean what units it uses? Microseconds (at least, in 2.4).
> >> >
> >> >
> >> > Actually what I meant was what that value is used for in the library.
> >> > The
> >> > phrase "time to live of client connection" confuses me. Does it
> really
> >> > mean
> >> > "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.
> >>
> >> TCP/IP connections, once created, will be retained for the specified
> >> (ttl) number of seconds. They'll be created when needed.
> >>
> >> The socket connect timeout is hard-coded to 1 second, and there's no
> >> timeout for I/O.
> >>
> >> >
> >> >
> >> > It is a little disturbing from a module-developer perspective to have
> >> > the
> >> > meaning of that parameter change by a factor of 1M between versions.
> >> > Would
> >> > it be better to revert the recent change and instead change the doc to
> >> > match
> >> > the current behavior?
> >>
> >> The doc was already changed to match the behavior, but I missed that.
> >> The caller I know of used the wrong unit, and I'll submit a patch to
> >> fix that in the caller, as well as revert my screw-up from yesterday.
> >>
> >> >
> >> > -Josh
> >> >
> >>
> >>
> >>
> >> --
> >> Born in Roswell... married an alien...
> >> http://emptyhammock.com/
> >
> >
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com> wrote:
> That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> right? That was where I stole my args from.
no, subversion
> As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> interface, I'm still not clear on exactly what that means. Does a value of
> 600 mean that a single multiget must complete in 600 microseconds otherwise
> it fails with APR_TIMEUP?
ttl only affects connections which are not currently used; it does not
control I/O timeouts
> That might explain the behavior I saw.
>
> I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
> but I'm hoping someone can bridge the gap between the socket-level
> explanation and the apr_memcache API call.
>
> I was assuming that apr_memcache created the TCP/IP connection when I called
> apr_memcache_server_create, and there even 600 seconds seems too short. Is
> the functionality more like it will create connections on-demand and leave
> them running for N microseconds, re-using the connection for multiple
> requests until TTL microseconds have elapsed since creation?
create on demand
reuse existing idle connections when possible
when performing maintenance on the idle connections, clean up any
which were idle for N microseconds
If a connection is always reused before it is idle for N microseconds,
it will live as long as memcached allows.
> If that's the case then I guess that every 10 minutes one of my cache
> lookups may have high latency to re-establish the connection, is that right?
> I've been histogramming this under load and seeing some long tail requests
> with very high latency. My median latency is only 143us which is great.
> My 90%, 95% and 99% are all around 5ms, which is fine as well. But I've got
> a fairly significant number of long-tail lookups that take hundreds of ms or
> even seconds to finish, and one crazy theory is that this is all reconnect
> cost.
>
> It would be nice if the TTL were interpreted as a maximum idle time before
> the connection is reaped, rather than stuttering response-time on a very
> active channel.
It is. The ttl is interpreted by the reslist layer, which won't touch
objects until they're returned to the list.
>
> This testing is all using a single memcached running on localhost.
>
> -Josh
>
>
> On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
>> wrote:
>> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
>> > wrote:
>> >>
>> >> If dlsym() is called with the special handle NULL, it is interpreted
>> >> as
>> >> a
>> >> reference to the executable or shared object from which the call is
>> >> being
>> >> made. Thus a shared object can reference its own symbols.
>> >>
>> >> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD
>> >> as
>> >> well.
>> >
>> >
>> > Cool, thanks.
>> >>
>> >> > Do you have a feel for the exact meaning of that TTL parameter to
>> >> > apr_memcache_server_create?
>> >>
>> >> You mean what units it uses? Microseconds (at least, in 2.4).
>> >
>> >
>> > Actually what I meant was what that value is used for in the library.
>> > The
>> > phrase "time to live of client connection" confuses me. Does it really
>> > mean
>> > "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.
>>
>> TCP/IP connections, once created, will be retained for the specified
>> (ttl) number of seconds. They'll be created when needed.
>>
>> The socket connect timeout is hard-coded to 1 second, and there's no
>> timeout for I/O.
>>
>> >
>> >
>> > It is a little disturbing from a module-developer perspective to have
>> > the
>> > meaning of that parameter change by a factor of 1M between versions.
>> > Would
>> > it be better to revert the recent change and instead change the doc to
>> > match
>> > the current behavior?
>>
>> The doc was already changed to match the behavior, but I missed that.
>> The caller I know of used the wrong unit, and I'll submit a patch to
>> fix that in the caller, as well as revert my screw-up from yesterday.
>>
>> >
>> > -Josh
>> >
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz <jm...@google.com> wrote:
> That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> right? That was where I stole my args from.
no, subversion
> As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> interface, I'm still not clear on exactly what that means. Does a value of
> 600 mean that a single multiget must complete in 600 microseconds otherwise
> it fails with APR_TIMEUP?
ttl only affects connections which are not currently used; it does not
control I/O timeouts
> That might explain the behavior I saw.
>
> I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
> but I'm hoping someone can bridge the gap between the socket-level
> explanation and the apr_memcache API call.
>
> I was assuming that apr_memcache created the TCP/IP connection when I called
> apr_memcache_server_create, and there even 600 seconds seems too short. Is
> the functionality more like it will create connections on-demand and leave
> them running for N microseconds, re-using the connection for multiple
> requests until TTL microseconds have elapsed since creation?
create on demand
reuse existing idle connections when possible
when performing maintenance on the idle connections, clean up any
which were idle for N microseconds
If a connection is always reused before it is idle for N microseconds,
it will live as long as memcached allows.
> If that's the case then I guess that every 10 minutes one of my cache
> lookups may have high latency to re-establish the connection, is that right?
> I've been histogramming this under load and seeing some long tail requests
> with very high latency. My median latency is only 143us which is great.
> My 90%, 95% and 99% are all around 5ms, which is fine as well. But I've got
> a fairly significant number of long-tail lookups that take hundreds of ms or
> even seconds to finish, and one crazy theory is that this is all reconnect
> cost.
>
> It would be nice if the TTL were interpreted as a maximum idle time before
> the connection is reaped, rather than stuttering response-time on a very
> active channel.
It is. The ttl is interpreted by the reslist layer, which won't touch
objects until they're returned to the list.
>
> This testing is all using a single memcached running on localhost.
>
> -Josh
>
>
> On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
>> wrote:
>> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
>> > wrote:
>> >>
>> >> If dlsym() is called with the special handle NULL, it is interpreted
>> >> as
>> >> a
>> >> reference to the executable or shared object from which the call is
>> >> being
>> >> made. Thus a shared object can reference its own symbols.
>> >>
>> >> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD
>> >> as
>> >> well.
>> >
>> >
>> > Cool, thanks.
>> >>
>> >> > Do you have a feel for the exact meaning of that TTL parameter to
>> >> > apr_memcache_server_create?
>> >>
>> >> You mean what units it uses? Microseconds (at least, in 2.4).
>> >
>> >
>> > Actually what I meant was what that value is used for in the library.
>> > The
>> > phrase "time to live of client connection" confuses me. Does it really
>> > mean
>> > "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.
>>
>> TCP/IP connections, once created, will be retained for the specified
>> (ttl) number of seconds. They'll be created when needed.
>>
>> The socket connect timeout is hard-coded to 1 second, and there's no
>> timeout for I/O.
>>
>> >
>> >
>> > It is a little disturbing from a module-developer perspective to have
>> > the
>> > meaning of that parameter change by a factor of 1M between versions.
>> > Would
>> > it be better to revert the recent change and instead change the doc to
>> > match
>> > the current behavior?
>>
>> The doc was already changed to match the behavior, but I missed that.
>> The caller I know of used the wrong unit, and I'll submit a patch to
>> fix that in the caller, as well as revert my screw-up from yesterday.
>>
>> >
>> > -Josh
>> >
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
right? That was where I stole my args from.
As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
interface, I'm still not clear on exactly what that means. Does a value of
600 mean that a single multiget must complete in 600 microseconds otherwise
it fails with APR_TIMEUP?
That might explain the behavior I saw.
I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
but I'm hoping someone can bridge the gap between the socket-level
explanation and the apr_memcache API call.
I was assuming that apr_memcache created the TCP/IP connection when I
called apr_memcache_server_create, and there even 600 seconds seems too
short. Is the functionality more like it will create connections on-demand
and leave them running for N microseconds, re-using the connection for
multiple requests until TTL microseconds have elapsed since creation?
If that's the case then I guess that every 10 minutes one of my cache
lookups may have high latency to re-establish the connection, is that
right? I've been histogramming this under load and seeing some long tail
requests with very high latency. My median latency is only 143us which is
great. My 90%, 95% and 99% are all around 5ms, which is fine as well.
But I've got a fairly significant number of long-tail lookups that take
hundreds of ms or even seconds to finish, and one crazy theory is that this
is all reconnect cost.
It would be nice if the TTL were interpreted as a maximum idle time before
the connection is reaped, rather than stuttering response-time on a very
active channel.
This testing is all using a single memcached running on localhost.
-Josh
On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
> wrote:
> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
> wrote:
> >>
> >> If dlsym() is called with the special handle NULL, it is interpreted
> as
> >> a
> >> reference to the executable or shared object from which the call is
> >> being
> >> made. Thus a shared object can reference its own symbols.
> >>
> >> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD
> as
> >> well.
> >
> >
> > Cool, thanks.
> >>
> >> > Do you have a feel for the exact meaning of that TTL parameter to
> >> > apr_memcache_server_create?
> >>
> >> You mean what units it uses? Microseconds (at least, in 2.4).
> >
> >
> > Actually what I meant was what that value is used for in the library.
> The
> > phrase "time to live of client connection" confuses me. Does it really
> mean
> > "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.
>
> TCP/IP connections, once created, will be retained for the specified
> (ttl) number of seconds. They'll be created when needed.
>
> The socket connect timeout is hard-coded to 1 second, and there's no
> timeout for I/O.
>
> >
> >
> > It is a little disturbing from a module-developer perspective to have the
> > meaning of that parameter change by a factor of 1M between versions.
> Would
> > it be better to revert the recent change and instead change the doc to
> match
> > the current behavior?
>
> The doc was already changed to match the behavior, but I missed that.
> The caller I know of used the wrong unit, and I'll submit a patch to
> fix that in the caller, as well as revert my screw-up from yesterday.
>
> >
> > -Josh
> >
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
right? That was where I stole my args from.
As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
interface, I'm still not clear on exactly what that means. Does a value of
600 mean that a single multiget must complete in 600 microseconds otherwise
it fails with APR_TIMEUP?
That might explain the behavior I saw.
I've now jacked that up by x1e6 to 600 seconds and I don't see timeouts,
but I'm hoping someone can bridge the gap between the socket-level
explanation and the apr_memcache API call.
I was assuming that apr_memcache created the TCP/IP connection when I
called apr_memcache_server_create, and there even 600 seconds seems too
short. Is the functionality more like it will create connections on-demand
and leave them running for N microseconds, re-using the connection for
multiple requests until TTL microseconds have elapsed since creation?
If that's the case then I guess that every 10 minutes one of my cache
lookups may have high latency to re-establish the connection, is that
right? I've been histogramming this under load and seeing some long tail
requests with very high latency. My median latency is only 143us which is
great. My 90%, 95% and 99% are all around 5ms, which is fine as well.
But I've got a fairly significant number of long-tail lookups that take
hundreds of ms or even seconds to finish, and one crazy theory is that this
is all reconnect cost.
It would be nice if the TTL were interpreted as a maximum idle time before
the connection is reaped, rather than stuttering response-time on a very
active channel.
This testing is all using a single memcached running on localhost.
-Josh
On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com>
> wrote:
> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl>
> wrote:
> >>
> >> If dlsym() is called with the special handle NULL, it is interpreted
> as
> >> a
> >> reference to the executable or shared object from which the call is
> >> being
> >> made. Thus a shared object can reference its own symbols.
> >>
> >> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD
> as
> >> well.
> >
> >
> > Cool, thanks.
> >>
> >> > Do you have a feel for the exact meaning of that TTL parameter to
> >> > apr_memcache_server_create?
> >>
> >> You mean what units it uses? Microseconds (at least, in 2.4).
> >
> >
> > Actually what I meant was what that value is used for in the library.
> The
> > phrase "time to live of client connection" confuses me. Does it really
> mean
> > "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.
>
> TCP/IP connections, once created, will be retained for the specified
> (ttl) number of seconds. They'll be created when needed.
>
> The socket connect timeout is hard-coded to 1 second, and there's no
> timeout for I/O.
>
> >
> >
> > It is a little disturbing from a module-developer perspective to have the
> > meaning of that parameter change by a factor of 1M between versions.
> Would
> > it be better to revert the recent change and instead change the doc to
> match
> > the current behavior?
>
> The doc was already changed to match the behavior, but I missed that.
> The caller I know of used the wrong unit, and I'll submit a patch to
> fix that in the caller, as well as revert my screw-up from yesterday.
>
> >
> > -Josh
> >
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com> wrote:
> On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
>>
>> If dlsym() is called with the special handle NULL, it is interpreted as
>> a
>> reference to the executable or shared object from which the call is
>> being
>> made. Thus a shared object can reference its own symbols.
>>
>> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as
>> well.
>
>
> Cool, thanks.
>>
>> > Do you have a feel for the exact meaning of that TTL parameter to
>> > apr_memcache_server_create?
>>
>> You mean what units it uses? Microseconds (at least, in 2.4).
>
>
> Actually what I meant was what that value is used for in the library. The
> phrase "time to live of client connection" confuses me. Does it really mean
> "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.
TCP/IP connections, once created, will be retained for the specified
(ttl) number of seconds. They'll be created when needed.
The socket connect timeout is hard-coded to 1 second, and there's no
timeout for I/O.
>
>
> It is a little disturbing from a module-developer perspective to have the
> meaning of that parameter change by a factor of 1M between versions. Would
> it be better to revert the recent change and instead change the doc to match
> the current behavior?
The doc was already changed to match the behavior, but I missed that.
The caller I know of used the wrong unit, and I'll submit a patch to
fix that in the caller, as well as revert my screw-up from yesterday.
>
> -Josh
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz <jm...@google.com> wrote:
> On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
>>
>> If dlsym() is called with the special handle NULL, it is interpreted as
>> a
>> reference to the executable or shared object from which the call is
>> being
>> made. Thus a shared object can reference its own symbols.
>>
>> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as
>> well.
>
>
> Cool, thanks.
>>
>> > Do you have a feel for the exact meaning of that TTL parameter to
>> > apr_memcache_server_create?
>>
>> You mean what units it uses? Microseconds (at least, in 2.4).
>
>
> Actually what I meant was what that value is used for in the library. The
> phrase "time to live of client connection" confuses me. Does it really mean
> "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.
TCP/IP connections, once created, will be retained for the specified
(ttl) number of seconds. They'll be created when needed.
The socket connect timeout is hard-coded to 1 second, and there's no
timeout for I/O.
>
>
> It is a little disturbing from a module-developer perspective to have the
> meaning of that parameter change by a factor of 1M between versions. Would
> it be better to revert the recent change and instead change the doc to match
> the current behavior?
The doc was already changed to match the behavior, but I missed that.
The caller I know of used the wrong unit, and I'll submit a patch to
fix that in the caller, as well as revert my screw-up from yesterday.
>
> -Josh
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as
> well.
>
Cool, thanks.
> > Do you have a feel for the exact meaning of that TTL parameter to
> > apr_memcache_server_create?
>
> You mean what units it uses? Microseconds (at least, in 2.4).
>
Actually what I meant was what that value is used for in the library. The
phrase "time to live of client connection" confuses me. Does it really
mean "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.
It is a little disturbing from a module-developer perspective to have the
meaning of that parameter change by a factor of 1M between versions. Would
it be better to revert the recent change and instead change the doc to
match the current behavior?
-Josh
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz <jm...@google.com> wrote:
>> Thanks Ben,
>>
>> That might be an interesting hack to try, although I wonder whether some of
>> our friends running mod_pagespeed on FreeBSD might run into trouble with
>> it. I did confirm that my prefork build has APR built with
>> APR_HAS_THREADS, which for some reason I had earlier thought was not the
>> case.
>
> It should work, provided you linked against libapr. The FreeBSD man
> page says this:
>
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as well.
>
>> Do you have a feel for the exact meaning of that TTL parameter to
>> apr_memcache_server_create?
>
> You mean what units it uses? Microseconds (at least, in 2.4).
Right. I screwed up on changing that yesterday. The APR doc was
already fixed long ago to indicate it was microseconds instead of
seconds, the Subversion code hasn't been fixed to respect that, and
the bug that was opened to fix the code to use seconds put me in the
wrong frame of mind :(
What does ttl mean for this particular API?
All resources in the resource list are cleaned up when the memcache
server is deleted/pool is cleared/destroyed.
Individual resources are returned to the list at the end of individual
memcache operations. When a resource is returned to the list, "old"
resources are destroyed, where "old" is determined by the ttl.
Destroying a memcache resource means it sends the "quit" message to
memcached and closes the socket. So ttl sets a limit on how long a
particular connection to memcached can be used.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as
> well.
>
Cool, thanks.
> > Do you have a feel for the exact meaning of that TTL parameter to
> > apr_memcache_server_create?
>
> You mean what units it uses? Microseconds (at least, in 2.4).
>
Actually what I meant was what that value is used for in the library. The
phrase "time to live of client connection" confuses me. Does it really
mean "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.
It is a little disturbing from a module-developer perspective to have the
meaning of that parameter change by a factor of 1M between versions. Would
it be better to revert the recent change and instead change the doc to
match the current behavior?
-Josh
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz <jm...@google.com> wrote:
>> Thanks Ben,
>>
>> That might be an interesting hack to try, although I wonder whether some of
>> our friends running mod_pagespeed on FreeBSD might run into trouble with
>> it. I did confirm that my prefork build has APR built with
>> APR_HAS_THREADS, which for some reason I had earlier thought was not the
>> case.
>
> It should work, provided you linked against libapr. The FreeBSD man
> page says this:
>
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as well.
>
>> Do you have a feel for the exact meaning of that TTL parameter to
>> apr_memcache_server_create?
>
> You mean what units it uses? Microseconds (at least, in 2.4).
Right. I screwed up on changing that yesterday. The APR doc was
already fixed long ago to indicate it was microseconds instead of
seconds, the Subversion code hasn't been fixed to respect that, and
the bug that was opened to fix the code to use seconds put me in the
wrong frame of mind :(
What does ttl mean for this particular API?
All resources in the resource list are cleaned up when the memcache
server is deleted/pool is cleared/destroyed.
Individual resources are returned to the list at the end of individual
memcache operations. When a resource is returned to the list, "old"
resources are destroyed, where "old" is determined by the ttl.
Destroying a memcache resource means it sends the "quit" message to
memcached and closes the socket. So ttl sets a limit on how long a
particular connection to memcached can be used.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: aprmemcache question
Posted by Ben Noordhuis <in...@bnoordhuis.nl>.
On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz <jm...@google.com> wrote:
> Thanks Ben,
>
> That might be an interesting hack to try, although I wonder whether some of
> our friends running mod_pagespeed on FreeBSD might run into trouble with
> it. I did confirm that my prefork build has APR built with
> APR_HAS_THREADS, which for some reason I had earlier thought was not the
> case.
It should work, provided you linked against libapr. The FreeBSD man
page says this:
If dlsym() is called with the special handle NULL, it is interpreted as a
reference to the executable or shared object from which the call is being
made. Thus a shared object can reference its own symbols.
And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as well.
> Do you have a feel for the exact meaning of that TTL parameter to
> apr_memcache_server_create?
You mean what units it uses? Microseconds (at least, in 2.4).
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
Thanks Ben,
That might be an interesting hack to try, although I wonder whether some of
our friends running mod_pagespeed on FreeBSD might run into trouble with
it. I did confirm that my prefork build has APR built with
APR_HAS_THREADS, which for some reason I had earlier thought was not the
case.
Do you have a feel for the exact meaning of that TTL parameter to
apr_memcache_server_create?
-Josh
On Thu, Sep 27, 2012 at 8:53 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz <jm...@google.com>
> wrote:
> > 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?
>
> I don't think there's an official way but you know apr was compiled
> with APR_HAS_THREADS when dlsym(NULL, "apr_os_thread_current") !=
> NULL.
>
> Using dlsym() like that is not quite compatible with POSIX but it
> works on all the major Unices.
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
Thanks Ben,
That might be an interesting hack to try, although I wonder whether some of
our friends running mod_pagespeed on FreeBSD might run into trouble with
it. I did confirm that my prefork build has APR built with
APR_HAS_THREADS, which for some reason I had earlier thought was not the
case.
Do you have a feel for the exact meaning of that TTL parameter to
apr_memcache_server_create?
-Josh
On Thu, Sep 27, 2012 at 8:53 AM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz <jm...@google.com>
> wrote:
> > 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?
>
> I don't think there's an official way but you know apr was compiled
> with APR_HAS_THREADS when dlsym(NULL, "apr_os_thread_current") !=
> NULL.
>
> Using dlsym() like that is not quite compatible with POSIX but it
> works on all the major Unices.
>
Re: aprmemcache question
Posted by Ben Noordhuis <in...@bnoordhuis.nl>.
On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz <jm...@google.com> wrote:
> 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?
I don't think there's an official way but you know apr was compiled
with APR_HAS_THREADS when dlsym(NULL, "apr_os_thread_current") !=
NULL.
Using dlsym() like that is not quite compatible with POSIX but it
works on all the major Unices.
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
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 <tr...@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz <jm...@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 <jm...@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 <tr...@gmail.com>
> wrote:
> >>
> >>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
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 <tr...@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz <jm...@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 <jm...@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 <tr...@gmail.com>
> wrote:
> >>
> >>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
>
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz <jm...@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 <jm...@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 <tr...@gmail.com> wrote:
>>
>>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
Re: aprmemcache question
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz <jm...@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 <jm...@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 <tr...@gmail.com> wrote:
>>
>>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
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?
-Josh
On Wed, Sep 26, 2012 at 7:17 PM, Joshua Marantz <jm...@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 <tr...@gmail.com> wrote:
>
>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
>>
>
>
Re: aprmemcache question
Posted by Joshua Marantz <jm...@google.com>.
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?
-Josh
On Wed, Sep 26, 2012 at 7:17 PM, Joshua Marantz <jm...@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 <tr...@gmail.com> wrote:
>
>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz <jm...@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/
>>
>
>