> Not critical at all. The duration_uS field can be set to -1 in the XDR > output to indicate that it is not implemented. I added this measurement > when porting to the 1.6 branch, where it makes more sense. I left it in > when I updated the 1.4 branch because, well, the overhead seemed > negligible and the numbers still seemed like they might be revealing > something (though I wasn't sure what exactly). The start-time field is > currently used as the "we're going to sample this one" flag. However > that could easily be changed to just set a bit instead. Two system > calls per sample would be saved. The practice of marking a transaction > to be sampled at the beginning and then actually taking the sample at > the end when the status is known could also be replaced by the old > scheme from last year where we do both steps at the same time. However > it was actually easier to implement with the two-step approach because > of the way that there are only two or three ways that a transaction can > start and a whole myriad of ways that it can end. So the first step > (the coin-tossing) only has to happen in those two or three places and > it's easier to know that you have counted everything once. Breaking it > up like this also gives you the choice of accumulating details > incrementally (the key, the status-code etc.) in whatever is the easiest > place.
Not totally sure I follow. The system calls would be nice to avoid, since we can't guarantee the system will use a vsyscall for the clock... > Yes, a client might well offer sFlow-MEMCACHE transaction samples (as > well as enclosing sFlow-HTTP transaction samples, if applicable). > However you would probably still want to instrument at the server end to > ensure that you were getting the full picture. There might be a whole > menagerie of different C, Python, Perl and Java clients in use. Many/most are based off of libmemcached. You can catch quite a bit with that one. > > 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 :) > > In the mean time I could strip down the current patch and reduce it's > code footprint considerably - but would that help? It could help to serve as a reference, but I'm not sure we can merge it. Every time we merge something we make some sort of idiotic pinkie swear to the planet to never touch that feature ever again forever. ASCII noreply haunts me to this day. Depending on how long 1.4 goes on though, it might end up having its own internal sampler, and thus sflow could be slapped on top of it. thanks, -Dormando
