httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <jmara...@google.com>
Subject Re: apr_memcache vs libmemcached
Date Thu, 19 Jul 2012 21:47:40 GMT
I think the point of that Wiki was that whoever wrote that entry claimed
that apr_memcached wasn't being actively worked on, but perhaps that's
false.  I don't think the implication was that the work was expected to
happen in code.google.com.

This question is in the context of
mod_pagespeed<https://developers.google.com/speed/pagespeed/mod>,
which currently uses the file system for caching that's visible across
Apache child processes.  That works pretty well but has limitations in
performance and network scope.  memcached is being considered as a possible
replacement for that.

I'll take a look at socache.


One of the advantages of libmemcached is that it supports -- or claims to
support -- asynchronous fetches, which we believe is important for
performance at scale.  However, I have not actually been able to get that
to work as expected, and have fallen back to a fairly synchronous model.
 The libmemcached API *looks* asynchronous -- it just doesn't seem to quite
work.   And if I'm going to stay synchronous then it might be a lot easier
to integrate if I use the built in APR support.  And even synchronous
fetches from memcached might be better than synchronous reads form disk.

Thanks,
-Josh


On Thu, Jul 19, 2012 at 5:39 PM, Nick Kew <niq@apache.org> wrote:

> On Thu, 19 Jul 2012 16:41:51 -0400
> Joshua Marantz <jmarantz@google.com> wrote:
>
> > Hi,
> >
> > Is anyone maintaining apr_memcache?  Or should I stick with libmemcached?
> >
> > This page: http://code.google.com/p/memcached/wiki/Clients suggests
> > apr_memcached is not maintained.
>
> Huh?  It's not maintained at google code since it was contributed
> to the core APR project.  If you have any reasonably recent APR
> installed (as you must have if you run httpd), it includes
> apr_memcache.
>
> Since you posted here I'd guess your purpose is writing a module?
> You might want to look at the socache modules as a higher-level
> abstraction.
>
>
> --
> Nick Kew
>

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