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

Performance problem pojo-cache

linusg Dec 14, 2009 8:24 AM

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"?>

server>

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

-->

<!--

Max number of elements which trigger replication

-->

<!-- 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.

-->

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

<FD_SOCK/>

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

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

<pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>

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

-->

<!--

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

-->

<!--

Number of milliseconds to wait until all responses for a

synchronous call have been received.

-->

<!--

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".

-->

</mbean>

server>