Next Major Memcached release / roadmap?

[Brad Fitzpatrick]

Iain,

Correct me if I'm wrong, but my understanding is that Tugela's use of BDB
is blocking, killing the non-blocking event-based nature of the memcached
core.  If that's the case, how do you justify blocking in the event loop?
Seems utterly terrible for performance, and would never be merged.
Unless BDB has some async API that you're using?  I haven't looked.

- Brad


On Sun, 17 Jun 2007, Iain Wade wrote:

> I would like to see tugela-cache's BDB backend merged directly into memcached.
>
> tugela-cache was a fork of an old memcache version for use in
> media-wiki/wikipedia. It ripped out the memory cache code and replaced
> it with BDB.
>
> Subsequent enhancements to memcache have not been kept up to date in
> tugela-cache. UDP support is not there, for example.
>
> If I coded/merged up a selectable backend patch which allowed a
> runtime choice, would it be acceptable to people?
>
> --Iain
>
> On 5/30/07, Paul Lindner <lindner at inuus.com> wrote:
> > I've been thinking of where memcached is now and where it might go in
> > the future.  I was hoping the community could come together and define
> > a roadmap of possible features to be added/incorporated in future
> > memcached releases.
> >
> > Some patches that are floating around and are not yet committed
> > include:
> >
> >  * non-expiring entries patch from Paul G
> >  * Ring buffers patch from Nathan.
> >  * Append data to existing entry from Filipe
> >
> > Also I have tasked myself with integrating some of Hi5's custom server
> > code into memcached.  This code would include variants of the
> > memcached storage architecture and some possible background worker
> > threads.
> >
> > Open issues that need consensus:
> >
> >   * Protocol changes -- do we want to extend memcached protocol to
> >     support new features?  If so, what is the logical way to do this.
> >
> >   * "Magic" values?  Do we want to allow some kind of mapping of
> >     client data to variations in server behavior?
> >
> >     For example the non-expiration patch allows you to configure a
> >     value that results in a non-expiring item.
> >
> >     Others have proposed that special features be enabled for a common
> >     prefix -- say all keys that have a  "ringbuffer:" prefix use that
> >     code path / storage engine..
> >
> >   * How do we accomodate new features without affecting performance.
> >
> >   * More? I'm sure there is..
> >
> >
> > Hopefully this gets things going.  I hope we can agree on the right
> > approach so we can incorporate as many community contributions as is
> > possible and feasible.
> >
> >
> > --
> > Paul Lindner        ||||| | | | |  |  |  |   |   |
> > lindner at inuus.com
> >
> >
>
>