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
