• Bug
  • Status: Closed
  • 3 Minor
  • Resolution: Cannot Reproduce
  • ehcache-core
  • interfaces
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • July 27, 2012
  • June 15, 2010

Description

I use 1.4.1 ecache.

I have the simplest case with self-populating cache and get() methods callled repeatedly in program, like:

public void testECache(){

ThreadMXBean mx = ManagementFactory.getThreadMXBean();

CacheManager cacheManager = new CacheManager();

HostUsageCache cache = new HostUsageCache( cacheManager, new HostUsageFactory(), “usage”);

long cpu = getCpuTime(mx);

for(int i=0;i< 10; i++){ for(int j=0; j< 100000; j++){ cache.get(“Start”+j+”end”+i); } long newcpu = getCpuTime(mx); System.out.println(“Cache Series “+i+” CPU “+(newcpu-cpu)/1000000000.0); cpu = newcpu;
}

}

private long getCpuTime(ThreadMXBean mx) { long sum = 0; for(long id : mx.getAllThreadIds()){ sum += mx.getThreadCpuTime(id); } return sum;

}

It appeared, that with the following configuration cache operations is extremely slows down on 100000 + 30000 elements:

The following configuration works OK:

Sourceforge Ticket ID: 2009685 - Opened By: astudnev - 3 Jul 2008 12:25 UTC

Comments

gluck 2009-09-25

Can you retest with 1.6.2 or the forthcoming 1.7.

The DiskStore is a lot slower but in these newer versions the Cache is not locked while disk access takes place, thus improving overrall performance. That’s the theory anyway. Please retest

Steve Harris 2009-10-15

Take a quick look and see if this is real or not.

Fiona OShea 2009-12-11

Please verify if this is really fixed