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.)
-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
More information about the memcached
mailing list