JBossCache performance issue.
mcevikce Jul 11, 2005 9:55 AMWe replaces our basic singelton hash based cache with jbosscache. I did some very basic performance testing, where first insert an object in the cache then retrieve an object from a cache 1000 times and meausre the time it took on milliseconds. My basic hash cache takes about 500millis while Jboss cache takes 14000millis for the same calls. Basically I have a new instance of TreeCache object created and configured once and make 1000 calls to get(fqn, key). What I see from the JProfiler is that most of the time is that TreeCache.get method is invoked 100 times when I drill down more I see that CacheStoreInterceptor class makes many calls to LockIntercoptor as well as UnlockInterceptor. It seems like most of the time is spent there.
I am running a Jboss 4.0.2 in clusterred HTTP session. Below is my JbossCache properties file. Please help me how I can tune Jboss or JbossCache to give me better performance.
com.bfm.app.viewserver.cache.loader.VSCustomCacheLoader
true
false
true
jboss:service=Naming
jboss:service=TransactionManager
<!-- Configure the TransactionManager -->
org.jboss.cache.JBossTransactionManagerLookup
<!--
Node locking level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ
<!--
Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
-->
LOCAL
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
TreeCache-Cluster
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
-->
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.3" mcast_port="48866"
ip_ttl="64" ip_mcast="true"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="false"/>
<PING timeout="2000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<FD shun="true" up_thread="true" down_thread="true"/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192" up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false" up_thread="false"/>
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
<!--
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
5000
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
10000
<!-- Max number of milliseconds to wait for a lock acquisition -->
15000
<!-- Name of the eviction policy class. -->
<!--
org.jboss.cache.eviction.LRUPolicy
-->
<!-- Specific eviction policy configurations. This is LRU -->
5
<!-- Cache wide default -->
5000
1000
5000
1000
5
4