I looked pretty hard at the shim idea back in May, but the engine protocol is really a different protocol. There was not a 1:1 correspondence with the standard memcached operations. If we define a standard sFlow-MEMCACHE measurement then it should be something that any memcache daemon can export, so it's really tied to the external spec, and shouldn't reflect anything about the internal structure of the implementation.
Instead I went back and tried to minimize the number of source code lines that would have to be added to memcached.c and thread.c. It's just a handful now. Pretty minimal. Neil On Aug 7, 2011, at 8:33 PM, Dustin wrote: > > On Aug 7, 6:01 pm, Andrew O'Brien <andr...@oriel.com.au> wrote: > >> Profiling for monitoring and activity estimation purposes - isn't that the >> point of the sFlow set of patches mentioned a few times on list? > > My opinion on the sFlow patches has been that it shouldn't be a > change to memcached. > > What can we do to memcached to make it easy for someone to deploy > this at runtime on an existing system? (well, assuming the system > doesn't have dtrace, anyway) > > The last conversation I had involved writing a shim engine to inject > the sFlow logic. I don't know that I've heard any reason that > wouldn't work. If there's something better we could do, let's do that > thing.
