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 <[EMAIL PROTECTED]> 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 ||||| | | | | | | | | |
[EMAIL PROTECTED]
