Comment #7 on issue 202 by [email protected]: TOP_KEYS feature fixes http://code.google.com/p/memcached/issues/detail?id=202
If I have understood correctly, I think you might want both features. A ring-buffer than clients can connect to and stream back using server-side filtering and sampling might be great for troubleshooting a single node. However the sFlow feature is aimed more at continuous operational monitoring of a whole cluster. If you have 1000 nodes in your cluster you wouldn't really want to open 1000 TCP connections from the monitoring client, so UDP logging makes more sense (especially if you are sampling anyway - lost packets are just an unintended adjustment to the sampling rate). With UDP logging it's more natural to pack the fields into a structure than to send a delimited ASCII string, so that's how you end up with the XDR encoding that sFlow uses. It's easy enough to turn it back into an ASCII stream at the client if you want to. That's what the "sflowtool" freeware does. I guess you could think of the UDP as an efficient mechanism to multiplex all the samples together from all the nodes.
I'm persuaded that there is at least some curiosity here, so I'll have a go at adding the engine shim. (Just finishing a module for nginx first...). Dustin persuaded me that the engine shim will only add one indirect function call to the critical path. That's a lot more cycles than the "if(--skip==0)" we had before, but my guess is that it still won't noticeably impact performance(?) Perhaps we can revisit that in due course.
