4 Replies Latest reply on Jan 16, 2007 8:49 AM by Sarath Krishnnan

    Performance Issue with Jbosscache

    M Muthukumaran Newbie

      We are using TreeCache as a placeholder in our application; we also have made this TreeCache as cluster aware.

      Following is the Jboss Cache configuration file

      <?xml version="1.0" encoding="UTF-8"?>
      
      <!-- ===================================================================== -->
      <!-- -->
      <!-- Sample TreeCache Service Configuration -->
      <!-- -->
      <!-- ===================================================================== -->
      
      <server>
      
       <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
      
      
       <!-- ==================================================================== -->
       <!-- Defines TreeCache configuration -->
       <!-- ==================================================================== -->
      
       <mbean code="org.jboss.cache.TreeCache"
       name="jboss.cache:service=TreeCache">
      
       <depends>jboss:service=Naming</depends>
       <depends>jboss:service=TransactionManager</depends>
      
       <!--
       Configure the TransactionManager
       -->
       <attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute>
      
       <!--
       Isolation level : SERIALIZABLE
       REPEATABLE_READ (default)
       READ_COMMITTED
       READ_UNCOMMITTED
       NONE
       -->
       <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
      
       <!--
       Valid modes are LOCAL
       REPL_ASYNC
       REPL_SYNC
       INVALIDATION_ASYNC
       INVALIDATION_SYNC
       -->
       <attribute name="CacheMode">REPL_ASYNC</attribute>
      
       <!--
       Just used for async repl: use a replication queue
       -->
       <attribute name="UseReplQueue">false</attribute>
      
       <!--
       Replication interval for replication queue (in ms)
       -->
       <attribute name="ReplQueueInterval">0</attribute>
      
       <!--
       Max number of elements which trigger replication
       -->
       <attribute name="ReplQueueMaxElements">0</attribute>
      
       <!-- Name of cluster. Needs to be the same for all clusters, in order
       to find each other
       -->
       <attribute name="ClusterName">SampleCluster</attribute>
      
       <!-- JGroups protocol stack properties. Can also be a URL,
       e.g. file:/home/bela/default.xml
       <attribute name="ClusterProperties"></attribute>
       -->
      
       <attribute name="ClusterConfig">
       <config>
      
       <TCP bind_addr="localhost" start_port="7800" loopback="true"/>
       <TCPPING initial_hosts="localhost[7800]" port_range="3" timeout="3500"
       num_initial_members="3" up_thread="true" down_thread="true"/>
       <MERGE2 min_interval="5000" max_interval="10000"/>
       <FD shun="true" timeout="2500" max_tries="5" up_thread="true" down_thread="true" />
       <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
       <pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100"
       retransmit_timeout="3000"/>
       <pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
       <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false"
       print_local_addr="true" down_thread="true" up_thread="true"/>
       <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
      
       </config>
       </attribute>
      
      
       <!--
       Whether or not to fetch state on joining a cluster
       NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive.
       -->
       <attribute name="FetchInMemoryState">true</attribute>
      
       <!--
       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
       -->
       <attribute name="InitialStateRetrievalTimeout">15000</attribute>
      
       <!--
       Number of milliseconds to wait until all responses for a
       synchronous call have been received.
       -->
       <attribute name="SyncReplTimeout">15000</attribute>
      
       <!-- Max number of milliseconds to wait for a lock acquisition -->
       <attribute name="LockAcquisitionTimeout">10000</attribute>
      
       <!-- Name of the eviction policy class. -->
       <attribute name="EvictionPolicyClass"></attribute>
      
       <!--
       Indicate whether to use marshalling or not. Set this to true if you are running under a scoped
       class loader, e.g., inside an application server. Default is "false".
       -->
       <attribute name="UseMarshalling">false</attribute>
       </mbean>
      
      
       <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
       <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
       <!-- <depends>jboss.cache:service=TreeCache</depends>-->
       <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
       <!-- </mbean>-->
      
      
      </server>
      


      When we profiled out application specific call, using profiler. We noticed a call in Jgroups object was running for 314 times in the given 15min (Total time in which the application call was tested). This 314 call took totally 6min of the total 15min, which is takes around 40% of the total time.

      Following is the method flow that we got in the profiler

      java.net.Socket.connect
       -org.jgroups.blocks.ConnectionTable.getConnection
       -org.jgroups.blocks.ConnectionTable.send
       -org.jgroups.protocols.TCP.sendUnicastMessage
       -org.jgroups.protocols.TCP.down
       -org.jgroups.stack.DownHandler.run
      


      The call to the Jgroups related classes never originated from our application code. We are not very sure from where this call are happening and how to stop them.

      Kindly let me know what might be the cause of the issue. We suspect that JbossCache using Jgroups internally and which is making this, calls.

      If this is not the right forum to report this issue, kindly direct me to the right place.


        • 1. Re: Performance Issue with Jbosscache
          Brian Stansberry Master

          You say you made it cluster aware. Is there actually a cluster involved? Your config shows it binding to localhost, so any cluster would have to be made up of nodes running on the same machine.

          Also what JGroups release is on the classpath? You can test by executing

          java -cp jgroups.jar;commons-logging.jar org.jgroups.Version


          from the dir where the jars are.

          • 2. Re: Performance Issue with Jbosscache
            M Muthukumaran Newbie

            Thanks for your interest.

            Actually we didn't have any cluster setup, while we took the performance results.

            We actually wanted to get the performance of the application with a single server instance. Kindly advice me, whether I am missing some setting here?

            Then, regarding the JGroups version, here is it

            Version: 2.2.8
            CVS: $Id: Version.java,v 1.18.2.1 2005/05/30 09:47:56 belaban Exp $
            History: (see doc/history.txt for details)
            


            The real thing that makes me worry is that the application flow, for which I am testing the performance, does not include any call to the Jboss Cache. We are using Jboss Cache for a different flow/purpose, mainly for invalidating the custom in memory architecture that we have in our application. But I am not sure why this JGroup call is coming in.

            Kinldy let me know any more information.


            • 3. Re: Performance Issue with Jbosscache
              Bela Ban Master

              Wait a minute, your CacheMode is REPL_ASYNC, which means that JBossCache tries to replicate each modfication ! Change that to LOCAL if you don't want replication, or use (a) transactions or (b) a replication queue if you want to bundle modifications.

              • 4. Re: Performance Issue with Jbosscache
                Sarath Krishnnan Newbie

                Hey,

                That was had got down the time taken for the calls to the jgroups, but we still are able to find the no of calls to be the same. Is there any way to eliminate the call to the jgroups at all.