Extended stats

[Just Marc]

Hi,

Okay.  How about enabling/disabling a set of extended stats on the fly?  
In a similar fashion to the latest logging patch.  That would have 
negligible impact when turned off.

Marc


> If someone does this, please make it optional. Preferably compile-time 
> optional. It's quite plausible that adding code to measure execution 
> time will itself have a significant impact on execution time and we 
> shouldn't have to spend those extra CPU cycles all the time.
>
> Also, make sure you know what you're measuring; if you measure, for 
> example, the time between receipt of a request and the last part of 
> the response being sent, then if the response is large you're really 
> measuring your network throughput rather than anything about memcached 
> per se since you'll have to wait for acknowledgements from the client 
> before you can finish sending the response.
>
> IMO response time measurement is probably more generally useful to put 
> in the client than the server, though I agree there's some value in 
> measuring from both sides (e.g. to isolate network problems based on 
> the client-side and server-side numbers varying significantly.)
>
> -Steve
>
>
> Just Marc wrote:
>> Hi,
>>
>> Along with a few really nice extra stats proposed here recently 
>> (which really should be implemented by someone with some time on 
>> their hands), I'd like to see a stat that accounts the avg time per 
>> request for all requests in the past 5 mins / past 1h, etc.     I 
>> could be pretty beneficial in some uses, especially for people who 
>> push memcache to its limits and or are trying to isolate performance 
>> issues or like to monitor every aspects of their systems.
>>
>> Thanks
>
>