stats in binary protocol

Toru Maesaka tmaesaka at gmail.com
Fri Jun 27 09:41:59 UTC 2008


Oops, forgot to reply to all.

Thanks for the reply Dormando! and excuse me for sending the same email twice :)

> No, I believe the intent was that the key would provide sets of
> information, not match specific information.

Fantastic :-) I was worried about this for a moment.

> Yeah. 'stats'.

Awesome!

> The idea was to make it simpler for the clients at a higher level. What
> this does is allow the clients to return arrays of key/value responses
> to their callers, instead of using some format that the client author
> would then need to parse.

This was really good to hear as my original intention was to return,
say, 'STAT <name> <value>\r\n' row at a time but after reading your
reply, I assume what we reaaaally want to do is include the key in the
response packet, like the getk command in the binary protocol right?
This way clients won't need to do any string parsing.

Please do correct me if I'm wrong :(

Toru

On Fri, Jun 27, 2008 at 5:26 PM, dormando <dormando at rydia.net> wrote:
> Toru Maesaka wrote:
>> Hi all,
>>
>> So I've been working on implementing the stats command over binary
>> protocol the last couple of days and came across few questions that I
>> would like to ask. My approach is based on the discussion from the
>> last hackathon. Heres a paragraph from Dustin's notes:
>
> Thanks for doing this :) Sorry I suck. I'll comment, but Dustin/etc
> should be able to comment on this as well :)
>
>> (1) Since the server sends back each row of an arbitrary stats output
>> at a time to the client, does this mean a given client should be able
>> to ask for any specific information? (e.g. a client could _only_ ask
>> for the pid of the server). This would make my life a little tricky
>> ;-)
>
> No, I believe the intent was that the key would provide sets of
> information, not match specific information.
>
>> (2) What should we do if a key wasn't contained in the request? I'm
>> thinking that this case should be treated the same as "stats\r\n" in
>> the ascii protocol. Is there any objections...?
>
> Yeah. 'stats'.
>
>> (3) What is the motivation behind sending row at a time?, when we
>> could serialize the entire output of an arbitrary stats output and
>> send it back to the client, like the current ascii approach (output
>> data is fairly small afterall). I'm asking this since this approach
>> would be relatively easy to pull off.
>
> The idea was to make it simpler for the clients at a higher level. What
> this does is allow the clients to return arrays of key/value responses
> to their callers, instead of using some format that the client author
> would then need to parse.
>
> Presently it's a one-liner in perl to parse stats, the libmemcached API
> "hates" the stats (but supports it, I think?), and designing it this way
> would make it dead simple for all of the languages to return arrays or
> hashmaps of the requested stats without any extra parsing code.
>
> Of course, anyone's free to comment here :)
>
> -Dormando
>


More information about the memcached mailing list