> > > >> On a positive note, it does seem like there is some consensus on the > >> value of random-transaction-sampling here. But do we have agreement > >> that this feed should be made available for external consumption (i.e. > >> the whole cluster sends to one place that is not itself a memcached > >> node), and that UDP should be used as the transport? I'd like to > >> understand if we are on the same page when it comes to these broader > >> architectural questions. > > > > I think I do agree with that. The question is whether we do that by > > making an sFlow interface or a sample interface? > > Do you mean a hook that can be used by a plugin to receive randomly > sampled transactions? That would allow you to inline the > random-sampling and eliminate most of the overhead. An sFlow plugin > would then just have to register for the feed; possibly sub-sample if > the internal 1-in-N rate was more aggressive than the requested sFlow > sampling-rate; marshall the samples into UDP datagrams, and send them > to the configured destinations. I like this solution because it means > the performance-critical part would be baked in by the experts and fully > tested with every new release. > > But if you've already done the hard work, and everyone is going to want > the UDP feed, then why not offer that too? I probably made it look hard > with my bad coding, but all you have to do is XDR-encode it and call > sendto().
We can ship plugins with the core codebase, so sflow would still work "out of the box", it just wouldn't be what the system was based off of. On that note, how critical is it for sflow packets to contain timing data? Benchmarking will show for sure, but history tells me that this should be optional. What would be pretty awesome is sflow-ish from libmemcached, since the only place it *really* matters how long something took is from the perspective of a client. Profiling the server is only going to tell me if the box is swapping, as it's extremely uncommon to nail the locks. > Finally, I accept that the engine-pu branch is the focus of future > development, but... any thoughts on what to do for the 1.4.* versions? I'm kicking out one release of 1.4.* monthly until 1.6 supersedes it. That said I have a backlog of bugs and higher priority changes that will likely keep me busy for a few months. Unless of course someone sponsors me to spend more time on it :) -Dormando
