On Fri, Jul 8, 2011 at 2:53 AM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
I've updated pull #414
(
https://github.com/infinispan/infinispan/pull/414) to work on top of
Vladimir's pull request, in case you want to have a look. You might
want to adjust the number of keys and/or disable some of the options
in the data providers before running it though, it takes a lot of time
to run (and it also needs -Xmx2000m).
I've left it running overnight on the test cluster (cluster01 and
cluster10), I'll send an update with the results in the morning.
Morning update:
Ok, apparently -Xmx2000m wasn't enough for 2 million keys, so I had to
start the tests again in the morning, running each scenario on a
different machine.
I haven't run the tests with concurrency level 512, as the total
number of threads is only 100, but I suspect the old LRU still won't
catch up with the new LRU's performance.
It's interesting that in the writeOnMiss test the new LRU performance
dropped when I increased the concurrency level from 32 to 128. I think
it might be because the eviction.thresholdExpired() check in
BCHM.attemptEviction() is done without a lock and so it could return
true simultaneously for multiple threads - which will all proceed to
wait on the segment lock and attempt eviction at the same time.
Another strange pattern is that neither eviction policy respects the
capacity parameter exactly. LIRS rounds up the capacity to the next
power of 2, and LRU/LRUOld do the same rounding and then multiply by
0.75.
I'll report again once I fixed these and once I update the reporting -
I think the total number of misses might be more relevant than the
standard deviation of the keys at the end.
Cheers
Dan