Hello JC and al.,
will your fixed size prefix patch (per prefix detailed statistics) be finally merged into mainline ? Thanks. Regards, Didier. On 24 juil, 11:37, JC <[email protected]> wrote: > By the way, is this patch going to be integrated in the mainline? > I mean, I would understand the whole feature to be kicked out but if > it kept in the official version, the opimized way to do things sounds > better, no? > > cheers, > Jean-Charles > > On Jun 1, 8:57 pm, Trond Norbye <[email protected]> wrote: > > > > > On Jun 1, 2009, at 6:53 PM, Jean-Charles Redoutey wrote: > > > > I kind of feel lonely on my topic ;-) > > > Anyway, still in the same area, I've made prefix stats collection > > > use the same pattern with per thread statistics and global > > > aggregation on request. Those stats overhead shall then not be more > > > than the other ones. > > > Which by the way lead me to a question: > > > Is it really useful to have per thread mutex? I mean, per > > > construction, this is only updated from one thread at a time, isn't > > > it? The only concurrent access is the global aggregation, in which > > > case atomic primitives should work perfectly (also I do agree, there > > > is nothing very portable :-( ), or even no locking at all could be a > > > solution, I mean aggregation may not see the "right" values because > > > of cache(s) and/or reordering stuffs but they would'nt be "so far" > > > from the true, which is already what stats command are answering > > > considering the thoughput usually going through memcached servers ... > > > cheers, > > > As they say: premature optimization is the root of all evil.. When we > > moved the status to a thread-local scope we wanted to make the stats > > "just as safe" as the old implementation, and optimize it later on if > > it ever turned up as a performance problem in a benchmark.... > > > Cheers, > > > Trond
