DataContainer performance review
by Vladimir Blagojevic
Hi,
I would like to review recent DataContainer performance claims and I was
wondering if any of you have some spare cycles to help me out.
I've added a test[1] to MapStressTest that measures and contrasts single
node Cache performance to synchronized HashMap, ConcurrentHashMap and
BCHM variants.
Performance for container BoundedConcurrentHashMap (LIRS)
Average get ops/ms 1063
Average put ops/ms 101
Average remove ops/ms 421
Size = 480
Performance for container BoundedConcurrentHashMap (LRU)
Average get ops/ms 976
Average put ops/ms 306
Average remove ops/ms 521
Size = 463
Performance for container CacheImpl
Average get ops/ms 94
Average put ops/ms 61
Average remove ops/ms 65
Size = 453
Performance for container ConcurrentHashMap
Average get ops/ms 484
Average put ops/ms 326
Average remove ops/ms 376
Size = 49870
Performance for container SynchronizedMap
Average get ops/ms 96
Average put ops/ms 85
Average remove ops/ms 96
Size = 49935
I ran MapStressTest on my Macbook Air, 32 threads continually doing
get/put/remove ops. Fore more details see[1]. If my measurements are
correct Cache instance seems to be capable of about ~220 ops per
millisecond on my crappy hardware setup. As you can see performance of
the entire cache structure does not seem to be much worse from a
SynchronizedMap which is great in one hand but also leaves us some room
for potential improvement since concurrent hashmap and BCHM seem to be
substantially faster. I have not tested impact of having a cache store
for passivation and I will do that tomorrow/next week.
Any comments/ideas going forward?
[1] https://github.com/infinispan/infinispan/pull/404
15 years
Alert from a failing test
by Sanne Grinovero
Hello all,
I'm not in state to fully debug the issue this week, but even though
this failure happens in the Lucene Directory it looks like it's
reporting an issue with Infinispan core:
https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/90/org...
In this test we're writing to the index, and then asserting on the
expected state on both nodes, but while it is successful on the same
node as the writer, it fails with
"java.io.IOException: Read past EOF" on the second node.
This exception can mean only one thing: the value, which is a
buffer[], was not completely transferred to the second node, which
seems quite critical as the caches are using sync.
I can't reproduce the error locally, but it's not the first time it is
reported by CI: builds 60, 62, 65 for example (and more) show the same
testcase fail in the same manner.
Cheers,
Sanne
15 years
Confluence
by Pete Muir
Hi all
I have added:
Galder
Manik
Mircea
Michal
Sanne
Vladimir
to Confluence as able to edit the docs. I can't seem to find:
Dan
Steve
Bela
Tristan
Trustin
Please can you guys log in once so I can give you permissions?
Also, anyone who I've missed, just ping me and I can give edit.
pete
15 years
