binary protocol notes from the facebook hackathon
brad at danga.com
Tue Jul 10 16:51:00 UTC 2007
On Tue, 10 Jul 2007, Paul Querna wrote:
> Brad Fitzpatrick wrote:
> > COMMANDS: (for cmd byte)
> > get - single key get (no more multi-get; clients should pipeline)
> > getq - like get, but quiet. that is, no cache miss, return nothing.
> > Note: clients should implement multi-get (still important for
> > reducing network roundtrips!) as n pipelined requests, the
> > first n-1 being getq, the last being a regular
> > get. that way you're guaranteed to get a response, and
> > you know when the server's done. you can also do the naive
> > thing and send n pipelined gets, but then you could potentially
> > get back a lot of "NOT_FOUND!" error code packets.
> This is missing the discussion about the GETQ putting the server into
> 'cork' mode, and any non-GETQ would uncork it. This would allow the
> server to optimize its own IO without nearly as much pain.
That seemed like a server implementation detail/optimization, not
something that client authors need to care about.
But yes, you're right... I forgot: it needs to be documented that you're
not guaranteed a response to a getq cache hit until you send a non-getq
command also, which uncorks the server.
> Also, as a client author, I really would prefer just having a NOOP or
> ECHO command at end of the bulk GETQ, rather than having to special case
> the last request. I guess I could just send a GET for a stats key or
> something, but that seems weird.
The "echo" command is on the jpg. I don't think anybody in the room cared
one way or another whether clients did getq*(n-1) + get or getq*n + noop.
I figure we'll add the noop/echo command to the server anyway, then
clients can choose which feels better to them... noop/echo or saving 12
bytes by special casing last one.
Doc updated in svn for both of your comments.
More information about the memcached