[jboss-user] [JBoss Cache] New message: "JBoss Cache usage: direct gets vs ordinary gets"

[Alex Reshetnyak]

User development,

A new message was posted in the thread "JBoss Cache usage: direct gets vs ordinary gets":

http://community.jboss.org/message/532238#532238

Author  : Alex Reshetnyak
Profile : http://community.jboss.org/people/areshetnyak

Message:
--------------------------------------------------------------
Hi all.
 
JBoss Cache provides access to data stored in it by API
 (cache.get(...), node.get(..)) and direct access by SPI
 (cacheSPI.peek(...), nodeSPI.getDirect(...)). What is the difference?
 Get operation invokes interceptor chain and also performs "visit"
 command, so node is marked as being used for eviction to save it in
 memory.
 Peek/getDirect operation omits cache mechanisms so data is returned
 quickly, but not marked as being in use.
 Currently we were using ordinary get operations, but faced a serious
 performance decrease in multi-thread environment (1700->400tps, see
 result below). The reason of it is BlockingQueue used in JBoss Cache
 for storing events (marking node as being used, so eviction saves it
 in memory). Using Peek/getDirect there is practically no decrease, but
 some eviction issues can be. Let's see on example.
 1. Put node /a to cache. Accessing it with get method rather often
 will trigger a visit event, so node will always remain in cache (in
 RAM).
 2. Put node /a to cache. Accessing it with Peek/getDirect will not
 trigger an event, so node will be evicted when it's age is greater
 than configured value (timeToLive). So, i.e. 120s it will be evicted
 and on next access will be read from store (DB).
 
 So what "evil" will be smaller?
 
Without use Peek/getDirect operatio to getting data from cache the many threads in our benchmark have state "wait".
These threads is locken in org.jboss.cache.RegionImpl.registerEvictionEvent, see screan shot 
http://community.jboss.org/servlet/JiveServlet/showImage/2342/%21%21_thread_dump.png 
 
 Result of Query benchmark:
 
 Threads              1                 2               3
 10 thread      ~1720tps     ~1760tps
 300threads   ~1750tps      ~390tps      1660tps
 
 1. Standalone configuration with Linked cache
 2. JBoss Cache-based configuration (current one)
 3. JBoss Cache-based configuration (current one), but with patched
 jcr.core, using peek/getDirect methods.
 
The JBossCache configuration :
<?xml version="1.0" encoding="UTF-8"?>
<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">

   <locking isolationLevel="READ_COMMITTED" useLockStriping="false" concurrencyLevel="50000" lockParentForChildInsertRemove="false"
      lockAcquisitionTimeout="20000" />

   <clustering mode="replication" clusterName="${jbosscache-cluster-name}">
      <stateRetrieval timeout="20000" fetchInMemoryState="false" />
      <jgroupsConfig multiplexerStack="jcr.benchmark.stack" />
      <sync />
   </clustering>

   <!-- Eviction configuration -->
   <eviction wakeUpInterval="2000">
      <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
         actionPolicyClass="org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.ParentNodeEvictionActionPolicy"
         eventQueueSize="1000000">
         <property name="maxNodes" value="1000000" />
         <property name="timeToLive" value="900000" />
      </default>
   </eviction>
</jbosscache>


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

To reply to this message visit the message page: http://community.jboss.org/message/532238#532238