"optimize" stats counters for mget

[GoogleCodeExporter]

We used to have two counter (one for hits and one for misses) we incremented 
when processed the 
mget command to avoid locking the global stats mutex all of the times. When we 
moved the get 
statistics down into the slab classes this got a lot worse, because now we have 
an array 201 
counters for get hits. Whenever we enter the function we have to zero out the 
array, and when we 
leave the function we need to iterate through the complete array to update the 
counters. In the 
latest revision we also use a thread-local statistics structure we aggregate 
whenever someone 
requests the statistics protected by a threadlocal mutex.

Instead of working on this temporary table we should update the threadlocal 
copy instead.

Original issue reported on code.google.com by trond.no...@gmail.com on 10 Sep 2009 at 7:03

[GoogleCodeExporter]

Patch:
http://github.com/trondn/memcached/commit/e84042e876739d5d675c4da83820b1c316beca
38

Original comment by trond.no...@gmail.com on 10 Sep 2009 at 7:18

• Changed state: Started

[GoogleCodeExporter]

Issue 81 has been merged into this issue.

Original comment by trond.no...@gmail.com on 10 Sep 2009 at 9:47

[GoogleCodeExporter]

This makes sense.  It's a lot more simple and I suspect it's more optimal in the
normal case.  The older code seemed optimized for very large text multigets at 
the
cost of assuming everything is a large multiget that may have touched a lot of 
slabs.

+8/-31 and fewer big loops is always good.

Original comment by dsalli...@gmail.com on 11 Sep 2009 at 5:07

[GoogleCodeExporter]

Original comment by dsalli...@gmail.com on 11 Sep 2009 at 5:08

• Changed state: Fixed