bernhard huber wrote:

Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...
Is there a way to revert back without re-implementing the whole thing?



running some tests i had following experiences

A       B
100     71ms
200    670ms
500   4917ms
1000 28221ms

A .. number of string entries to be cached
B .. measured time in ms

Seems that caching time rises not linear using JCS.


Memory cache is implemented by org.apache.jcs.engine.LRUMemoryCache, and I think it is being used by Cocoon (as configured in default.ccf). Method of adding an entry looks like O(log(n)), with the exception of one statement:


   if ( map.size() != dumpCacheSize() )
   {
     log.error( "update: After spool, size mismatch: map.size() = "
                + map.size() + ", linked list size = " +
                dumpCacheSize() );
   }

Which forces linear scan of linked list. For large caches, this should be one of the reasons of slow performance. Another reason I can think of can be synchronization in the heavy-multithreaded environment.

Pier, you can also take a look at MRUMemoryStore / MRUBucketMap pair- it supposed to be faster replacement of excalibur's store.

Vadim



Reply via email to