stats in binary protocol

Toru Maesaka tmaesaka at gmail.com
Sun Jun 29 06:39:24 UTC 2008


Dustin, Dormando,

Thanks for the feedback, you guys got rid of my concerns :)

> Toru; Putting the key in the response packet is what I meant, yes. So
> there's no encoding, except probably formatting everything (numbers, other
> strings) as strings in the value. This is, as you said, in alternative to
> encoding "<stat> = value" in the value part of the response packets.

Sounds good!

>> Part of what we discussed was having the stats processed by multiple parts
>> of the server.  That is, there are stats that are core (such as PID, rusage,
>> number of hits and misses, etc...), stats that are engine-specific (such as
>> how many items total exist, LRU eviction stats, etc...) and possibly others.
>>  This means that a stats request has to be passed around with a consistent
>> API to emit values back to the client

Gotcha. I will keep this in mind when I design the approach.

Okay, so let me get back to you guys when I have something decent to
show (though I assume we'll be chatting on IRC much sooner than that).

Have a good weekend,
Toru


On Sat, Jun 28, 2008 at 3:08 AM, dormando <dormando at rydia.net> wrote:
> Knew I was forgetting an important detail there :)
>
> Toru; Putting the key in the response packet is what I meant, yes. So
> there's no encoding, except probably formatting everything (numbers, other
> strings) as strings in the value. This is, as you said, in alternative to
> encoding "<stat> = value" in the value part of the response packets.
>
> I'll also echo Dustin's sentiments that the implementation is more up to
> you, I'm just echoing what we discussed prior, and Dustin's arguments below
> are more of the reason why multi-response looks to be the right way.
>
> No strong opinions on returning an error or not on unmatched stats commands
> though.
>
> -Dormando
>
>> Well, as the one doing the implementation, I think you probably have a bit
>> more leverage at the moment to decide what's wrong.  :)
>>
>> The general spirit of stats argument is that it's interpreted by the
>> server.  So we *could* decide that it's a good idea to have an argument in
>> the form of general:pid to return only the pid if it made sense.  The only
>> downside is that it'd have to be supported for a while.
>>
>> Part of what we discussed was having the stats processed by multiple parts
>> of the server.  That is, there are stats that are core (such as PID, rusage,
>> number of hits and misses, etc...), stats that are engine-specific (such as
>> how many items total exist, LRU eviction stats, etc...) and possibly others.
>>  This means that a stats request has to be passed around with a consistent
>> API to emit values back to the client.
>>
>> This is another reason the ``multi-response'' thing is necessary.  An
>> engine may have a *lot* of stats it wants to emit, and buffering that all up
>> and formatting it for a given protocol could be difficult and would slow
>> things down/use more memory.  It all just kind of works its way out like
>> this.  Formatting is handled by the protocol handler, and content is handled
>> by the thing that knows.
>>
>> It is important at this point to determine what it means to provide an
>> argument the server doesn't understand (and what it means to not understand
>> it) in this case.  You could infer that if nobody emitted a response, there
>> was nothing interesting to say about it, or you could have the API actually
>> indicate whether or not the component actually understood the stat argument.
>>  Does it even matter?  We could also just say, ``If the server has something
>> to say about your argument, it will.''
>
>


More information about the memcached mailing list