Next Major Memcached release / roadmap?

[Randy Wigginton]

I've used MySQL as a DB backend to memcache with very good results;  
I'm not caching everything though, it is used sparingly.

When I investigated BDB with memcache, the blocking issue was a real  
performance issue.  Also syncing to the filesystem became a real slow  
& expensive operation.

On Jun 16, 2007, at 11:57 AM, Brad Fitzpatrick wrote:

> 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
>>>
>>>
>>
>>
>