Extended stats

Steven Grimm sgrimm at facebook.com
Thu Apr 12 17:58:22 UTC 2007

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.)


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

More information about the memcached mailing list