[Chicken-users] memcached

[Alaric Snell-Pym]

Hi folks,

I'm just assembling an egg to act a a memcached client.

Memcached is described here:

http://danga.com/memcached/

The memcached protocol is documented here:

http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt

It's a fairly simple text-commands-over-TCP job, but the fun part is
that one provides it with a list of servers, each with a weighting.
The client then implements a hash table, with servers as buckets,
thus spreading the cache across a cluster of servers.

For situations where a cache is useful, this tends to give you quite
a large speed boost on big installations, since you can have hundreds
of memcached servers. Facebook is rumoured to have 200 with 2TB of
RAM used for caching, etc.

Anyway - so far I've implemented the memcache client protocol, the
internal interface used to talk to a memcache server. What I need to
do next is:

1) Write the cluster client, which uses the aforementioned to talk to
each server in a cluster, with hashing of objects across the pool
(and decent handling of servers in the cluster failing).

This will provide a native memcache-specific API, which the egg will
export. Keys are scheme strings, while values are u8vectors.

2) Write a second egg containing a Scheme-friendly API for caches.
This will involve a simple abstraction for caches, with 'null' (never
remembers anything), 'in-memory' (just uses a hash table in RAM) and
'namespace' (uses a parent cache, but inserts a prefix onto keys in
order to isolate from other uses of the same cache) implementations.
Keys and values can now be arbitrary s-expressions (although
memcached keys cannot contain spaces, so I'm going to need to work
out some encoding).

The basic cache API will mirror memcached's fairly sensible set of
operations: (get key), (set key value), (add key value), (replace key
value) and (delete key). 'add' is like 'set', but will do nothing if
the key already exists. 'replace' is like 'set', too, but will do
nothing if the key does NOT already exist. Both are handy for
reducing race conditions in a cache shared between threads and the like.

 - On top of that, an implementation of memoize that uses a cache
object as the storage. So one can memoize a costly function, with a
big shared cache of hundreds of servers! Wow! Or just using a normal
in-memory cache.

 - Maybe a filesystem-backed cache implementation, too, one day. If
people want it.

3) Write a memcached-backed implementation of the generic cache
abstraction, and put it in the memcached egg.

The end result will be that it'll be possible to:

1) Write clients that depend on particular memcache features (such as
incr and decr), or that need direct access to the u8vector
representation of memcache values (eg, to interoperate with clients
written in other languages, using the same cache), or that perform
memcache administration (flushing the caches, etc)

2) Easily and pleasantly write software that uses a cache, but with a
choice of null (for debugging), in-memory (for small setups) and
memcached (for big setups) backends, all behind a common API so your
code doesn't need to know or care.

But I'd like some feedback...

I could incorporate both eggs into one, but then apps that want to
use the in-memory cache would get a memcached implementation, too.
Said implementation wouldn't be very big, but still, it's not good to
bloat things. I'm open to the decision of the community on this one.
One egg that contains the generic cache API with all the backends,
and a separate API for low-level access to memcached? Or two separate
eggs?

And do we think this counts as a *networking* egg (since memcached is
a network protocol) or a *databases* egg (my choice, but some might
say that something that forgets things of its own accord isn't a
database).

Either way, I'd like a subversion repository login, please. Whether
or not I have an egg called 'memcached' as well, I'll certainly make
an egg which I propose to innovatively called 'cache'. My favourite
username is 'alaric', and my favourite colour is dark blue.

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4