November 17, 2009

I’ve been using this technique on django views and Juno for some time. It’s just a decorator which inspect the parameters given to a function to search for a key on memcached.

You will find two files on github: no_decorator_example.py and decorator_example_memcache.py. Both of them search on twitter for a given term. The first script executes the search everytime, and the second script implements a 60 second cache, which uses the parameter (search term) as key.

I’m sure there must be another way to deal with parameters without the wrapper class, but so far nothing I’ve tried gave the same result.

For Django views, one could go so far as using return HttpResponse(your_response, mimetype=’text_plain’) too.

Ezra Zygmuntowicz’ Nanite was presented at erlang factory (which I may or may not write about later) and seems like a perfect case of AMPQ and queue use (I got a pretty solid understanding of routing keys from it).

The captain obvious one: if its the case, make sure the way you store your data is readable between different languages. For example, storing in python and reading in java or ruby a pickled object is trivial, but persisting some specific objects, like rails is prone to do, may render the data almost unreadable. Try to use simple serialization formats if possible (like yaml, json, xml).

The other captain obvious one: saving and invalidating data must be done by the application responsible for its integrity, for simplicity and safety sake. Remember cache 101: a cache is not a database. It’s not searchable, and its data must reflect a coherent source of data.

The not so obvious one: if you use more than a memcached server, make sure both clients understand the hashing algorithm which is used to select the right server for the key you are asking. When using the same language and client this is transparent, but there different known ways to select the right server as:

md5 hash of the key

crc32 based hash

native hash (as String.hashCode() in java)

pure magic hash (some clients implement non-standard memcache

The case in point is a ruby application using the memcache-client gem and a java application using whalin’s client. If you use more than one server, the ruby client uses it’s unique algorithm, which is CRC32 based. The java client defaults to a NATIVE based algorithm, but contains 3 more algorithms. Keys would never get correct hits this way.

Let’s see how it works :

Code for hashing in Ruby (straight from memcache_client gem)

# Note that the method crc32_ITU_T is a patch for the String class from memcache_client
def hash_for(key)
(key.crc32_ITU_T >> 16) & 0x7fff
end

The memcache client was required just to attach the crc32_ITU_T() method to the String class, but if you dont want to install it, just paste the following code (which is part of memcache_client) instead:

Their API is clean and the text parsing very accurate.Choose “Napkin” in the style combo and click draw to see their demo.

I found it via another gem, this caching 101 page for dummies. Things like this and this ‘Threads primer’ are necessary reminder nowadays. There are a lot of butchered applications and architectures popping everywhere, and without these kind souls providing the best of them going thru basic concepts, we’re all doomed.

There goes my contribution, a kind of memcached 101, both in napkin and blue modern styles !

memcached 101 napkin style

memcached 101 blue modern style

Paste the code below to generate these diagrams. Note the alt 'command' I used to put both cases in the same diagram.
Gotta love that.

Alice->Application: Asks for her Profile
Application->Memcached: is Alice profile there \?
alt Data is not cached yet
Memcached->Application: No, it's not here
Application->Database: get me Alice's Profile
Database->Application: here is the data - it took me a lot of time, k \?
Application->Memcached: set Alice Profile there
else data is already cached yay
Memcached->Application: Got it
end
Application-->Alice: Response (her profile data)