0 Replies Latest reply on Dec 14, 2009 8:24 AM by L G

    Performance problem pojo-cache

    L G Newbie

      Hi,

       

      I'm a little bit new to joboss cache so I'm sorry if I write strange things that doen's make sense.

       

      I've implemented a general cache solotion for replicating objects between 2 servers, I'm using pojo-cache (jbosscache-pojo-2.2.1.GA-all), I've also tried version (jbosscache-pojo-3.0.0.GA-all), with both version I changed javaassist.jar to 3.10GA after some aocp compile issues.

       

      Same problem in both version, but I now use 2.2.1 becasue it seems like 3.0.0 has some kind och memory issue; (I haven't really looked into it but my app runs out of memory.)

       

      The test env is 2 powerful worksations (2xQuadcore,8GB ram) on a gigabit network, the test is done during no load and the result is just read from timeing in the logs. I have the same problem on linux...

       

      I don't really need synchron cache so right now I use REPL_ASYNC and READ_UNCOMMITTED.

       

      I tried REPEATABLE_READ and REPL_SYNC but performance is so bad.

       

      First, replication works fine it is just performance issue.

       

      I assume I'm using it the wrong way or have some error in my config. When having REPEATABLE_READ and REPL_SYNC it takes 2-8 sec to attach an object with maybe 40 attributes (ink 3 concurrant hashmaps with size=4 each). Detach also takes many second. Using REPL_ASYNC and READ_UNCOMMITTED I'm down at 100ms but I still think it is bad.

       

       

      Some questions...

       

      What performance shall I expect?

       

      I have 5 PojoCache obejcts, is it a problem that each of my 5 pojo cach objects use the same replSynk xml file?

       

      Each of my PojoCache object holds one (or a couple) of <key, ConcurrantHashMaps> so I always get the  Map from the cache with the key, then I work with the object in the map. Can that be a problem, I rember reading that only each attribute in an object will replicate even if it is in a map.

       

      Do my replSynk file look ok? (See below)

       

      ---------------------------------

      <?

       

      xml version="1.0" encoding="UTF-8"?>

       

      <!-- ===================================================================== -->

      <!-- -->

      <!-- Sample TreeCache Service Configuration -->

      <!-- -->

      <!-- ===================================================================== -->

       

      <

       

      server>

       

       

      <!-- ==================================================================== -->

       

      <!-- Defines TreeCache configuration -->

       

      <!-- ==================================================================== -->

       

       

      <mbean code="org.jboss.cache.jmx.CacheJmxWrapper"

       

      name="jboss.cache:service=PojoCache">

       

       

      <depends>jboss:service=Naming</depends>

       

      <depends>jboss:service=TransactionManager</depends>

       

       

      <!--

      Configure the TransactionManager

      -->

       

      <attribute name="TransactionManagerLookupClass">se.kojak.common.cache.KjTransactionManagerLookup</attribute>

       

       

      <!--

      Isolation level : SERIALIZABLE

      REPEATABLE_READ (default)

      READ_COMMITTED

      READ_UNCOMMITTED

      NONE

      -->

       

      <attribute name="IsolationLevel">READ_UNCOMMITTED</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 TreeCache nodes in a

      cluster in order to find each other.

      -->

       

      <attribute name="ClusterName">dev-JBossCache-Cluster</attribute>

       

       

      <!--Uncomment next three statements to enable JGroups multiplexer.

      This configuration is dependent on the JGroups multiplexer being

      registered in an MBean server such as JBossAS. -->

       

      <!--

      <depends>jgroups.mux:name=Multiplexer</depends>

      <attribute name="MultiplexerService">jgroups.mux:name=Multiplexer</attribute>

      <attribute name="MultiplexerStack">fc-fast-minimalthreads</attribute>

      -->

       

       

      <!-- JGroups protocol stack properties.

      ClusterConfig isn't used if the multiplexer is enabled and successfully initialized.

      -->

       

      <attribute name="ClusterConfig">

       

      <config>

       

      <UDP mcast_addr="228.10.10.10"

       

      mcast_port="45588"

       

      tos="8"

       

      ucast_recv_buf_size="20000000"

       

      ucast_send_buf_size="640000"

       

      mcast_recv_buf_size="25000000"

       

      mcast_send_buf_size="640000"

       

      loopback="false"

       

      discard_incompatible_packets="true"

       

      max_bundle_size="64000"

       

      max_bundle_timeout="30"

       

      use_incoming_packet_handler="true"

       

      ip_ttl="2"

       

      enable_bundling="true"

       

      enable_diagnostics="true"

       

       

      use_concurrent_stack="true"

       

       

      thread_naming_pattern="pl"

       

       

      thread_pool.enabled="true"

       

      thread_pool.min_threads="1"

       

      thread_pool.max_threads="25"

       

      thread_pool.keep_alive_time="30000"

       

      thread_pool.queue_enabled="true"

       

      thread_pool.queue_max_size="10"

       

      thread_pool.rejection_policy="Run"

       

       

      oob_thread_pool.enabled="true"

       

      oob_thread_pool.min_threads="1"

       

      oob_thread_pool.max_threads="4"

       

      oob_thread_pool.keep_alive_time="10000"

       

      oob_thread_pool.queue_enabled="true"

       

      oob_thread_pool.queue_max_size="10"

       

      oob_thread_pool.rejection_policy="Run"/>

       

       

      <PING timeout="2000" num_initial_members="3"/>

       

      <MERGE2 max_interval="30000" min_interval="10000"/>

       

      <FD_SOCK/>

       

      <FD timeout="10000" max_tries="5" shun="true"/>

       

      <VERIFY_SUSPECT timeout="1500"/>

       

      <pbcast.NAKACK max_xmit_size="60000"

       

      use_mcast_xmit="false" gc_lag="0"

       

      retransmit_timeout="300,600,1200,2400,4800"

       

      discard_delivered_msgs="true"/>

       

      <UNICAST timeout="300,600,1200,2400,3600"/>

       

      <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"

       

      max_bytes="400000"/>

       

      <pbcast.GMS print_local_addr="true" join_timeout="5000"

       

      join_retry_timeout="2000" shun="false"

       

      view_bundling="true" view_ack_collection_timeout="5000"/>

       

      <FRAG2 frag_size="60000"/>

       

      <pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>

       

      <!-- <pbcast.STATE_TRANSFER/> -->

       

      <pbcast.FLUSH timeout="0"/>

       

      </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

      state (ie. the contents of the cache) are retrieved from

      existing members in a clustered environment

      -->

       

      <attribute name="StateRetrievalTimeout">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>

       

       

      <!--

      Indicate whether to use region based 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="UseRegionBasedMarshalling">true</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>