Note that JBC3 only supports REPEATABLE_READ and READ_COMMITTED. So your READ_UNCOMMITTED setting effectively gets upgraded to READ_COMMITTED.
What's the purpose of setting your eviction wakeup interval to 0? You realise that the eviction thread will not run with such a setting, so your eviction settings after that are pointless.
Finally, in your test, is this run with a single thread? Do you have anything else happening at the same time, e.g., writers? Have you tried profiling this? If you don't have any other concurrent activity, especially writes, the spikes you see could be GC spikes, as it does seem to be pretty regular. What memory settings have you configured your VM with?
Thank you for your reply.
I changed config file to use REPEATABLE_READ, as well as wakeUpInterval. But that does not impact the result much. BTW, I use default JVM setting.
We plan to use jboss cache to share some data in cluster environment. 99% will be read activity, and the data in cache is most Hashmap. We will access cache up to 20 thousand times per transaction, but like to keep response time as fast as possible.
How do I tune Jboss cache (and JVM) to get best performance?
READ_COMMITTED would actually give you better performance if you don't require REPEATABLE_READ guarantees.
wakeUpInterval - if you don't need eviction, then remove the whole eviction XML block. From your initial post it seems as though you were not using it and hence didn't need it? If you do need it then that's a different story.
Do your reads happen inside of a transaction? E.g., do you do :
1. Start tx
2. Read stuff
3. End tx
Or were you using "transactions per second" to mean "operations per second"?
Regarding JVM tuning, that's a whole science in itself and will depend on a bunch of parameters including, but not limited to, system architecture (32 vs 64 bit), operating system, JVM version and vendor, operating environment (e.g., app server config) memory requirements of your application itself, amount of and type of data cached, etc.