Notes from the fourth memcached hackathon of undetermined
dustin at spy.net
Wed Apr 16 22:40:36 UTC 2008
On Apr 16, 2008, at 15:22, mike wrote:
> On 4/16/08, Dustin Sallings <dustin at spy.net> wrote:
>> * get (returns an object or error; does not return key)
>> * getq (returns an object; does not return missing; does not
> is the "q" something like "get quietly" ?
Yes, it's the quiet get we defined from the first meaning. It only
returns data, never returns anything on a miss (but could signal an
>> * getk (returns an object with key or error)
>> * getkq (returns an object with key; does not return missing)
> Do any of these return a "cache miss" message, or does it only return
> if there is an error? If I read this right, "get" and "getk" both
> return a miss...
That is correct. You do not get a cache miss message for q commands.
> I could see client libraries benefitting from a "miss" message (for
> all I know it could already be in the protocol though and my client
> just doesn't do anything with it.)
Clients and servers benefit greatly from *not* having miss messages.
Imagine needing 1,000 keys for which only 100 are actually in the
server. You could issue 1,000 quiet gets and a noop (or 999 getq
commands and a get) and only have to deal with hits. The misses are
This is the same way the text protocol works today, except it's been
generalized slightly more and made a bit easier to deal with by not
having to have one command that takes an arbitrary number of variable
width keys that the server has to understand how to separate. All the
server wants to know is whether you want a response on a miss, and
(now) whether you want the key returned as well.
More information about the memcached