How well does JBossCache perform? This is a question a lot of people have asked us. This is just a start, but hopefully this page will grow to contain a wealth of knowledge on the performance characteristics of JBossCache.
2. About the tests
The characteristics of each test are as follows:
3 test cases are run:
50PercentRead - 50% of the accesses are gets while 50% are puts.
75PercentRead - 75% of the accesses are gets while 25% are puts.
90PercentRead - 90% of the accesses are gets while 10% are puts.
Each test case is run in 2 different modes:
Single-node tests read and write to the same node in the TreeCache.
Multi-node tests read and write to different nodes in the TreeCache.
All caches use FIFOPolicy as an EvictionPolicy, with the following settings:
maxNodes = 2000
ttlSeconds = 600
wakeupIntervalSeconds = 10
Tests are run using 10 concurrent worker threads, each one looping through the test 100,000 times to arrive at 1,000,000 iterations per test before averages are calculated.
Tests conducted on RHEL 3/2.4 Kernel, 2 x 3.06 GHz P4 Xeon CPUs, 2 GB RAM, using Sun JDK1.5.0_05
All times measured are in milliseconds, to perform 100 operations. E.g., a figure of 12.5 would mean 0.125 millis per operation.
JBoss JRunit was used to measure benchmarks.
3. Local caches
This section attempts to compare JBossCache running as a local cache (i.e., non-replicated). Here, we compare the following caches tested:
JBossCache with Pessimistic locking (default), and Isolation Level set to NONE
JBossCache with Pessimistic locking (default), and Isolation Level set to REPEATABLE_READ (default)
JBossCache with Optimistic locking (experimental)
Note that some of the tests are skipped for certain caches tested:
Multi-node is skipped when using a HashMap, since HashMaps have no concept of 'nodes'.
Single-node is skipped when using Optimistically locked caches, since this will always result in transaction rollbacks (locks are held on a node level).