On Aug 8, 10:00 pm, neilmckee <[email protected]> wrote: > > Well, all the memcached operations are built on top of it... do you > > mean specifically multiget might call into the engine multiple times > > for a single "request"? > > Yes. That's one example. I think there were others where the > memcache operation resulted in more than one engine transaction.
Allocation is a separate engine request from linking. You can just do whatever is sensible there, though. The binary protocol doesn't necessarily have packet responses for many engine requests, but packet requests map pretty well to engine requests. The text protocol has a special-case "multiget" which behaves differently. > Although there are already 30+ companies and open-source projects with > sFlow collectors I fully expect most memcached users will write their > own collection-and-analysis tools once they can get this data! Don't > you agree? So it's not about any one collector, it's about > defining a useful, scalable measurement that everyone can feel > comfortable using, even in production, even on the largest clusters. I don't think I've ever said anything that sounds like a disagreement with you. I just disagree that it's impossible to build memcached such that sFlow collection is an externally produced plugin. I could be wrong, but I don't understand why we can't do it with the engine interface or why we can't design another interface that would be useful. > 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? (And why can't everyone just use dtrace?)
