On Sun, Mar 25, 2012 at 12:16 PM, dormando <[email protected]> wrote: >> Thanks. Any reason to move item_lock(s) back to cache_lock ? >> >> We've done preliminary performance runs using memaslap. Memory limits >> are altered from 32MB up to 2GB. The total transaction-per-second >> numbers drop as the memory limits are increased. All other parameters >> take the defaults based on memcached 1.4.11. The thing concerns (and >> puzzles) me most is the get hit counts that are flat after memory >> limit is set to 256 MB. Get and put ratio is 9:1 (using default). Data >> size is 1K, key size is 100 bytes. >> >> I suspect the flat-ness is caused by slabs_lock. Any one saw a similar >> "flat-ness" before (and knows the bottleneck) ? Enclosed a chart that >> shows this issue. > > I was never able to get good numbers out of memslap, and memaslap is even > buggier and worse. > > mc-crusher should work much better for testing: > https://github.com/dormando/mc-crusher > > it doesn't do short run tests, it does steady state testing while you > measure the rate via memcached's stats.
Thanks .. We'll try it out on next test. BTW, anyone knows a good way to measure how a command spends time inside its code path ? Specifically, how long it spends on network processing and how long it spends on hash search ? Thanks, Wendy
