We 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
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884376#3884376
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884376
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
