OK, here are the final results.
We did series of tests on the following wakeUpIntervalSeconds: 1,3,5,10,15. The default one indicated in the sample code on your site was 5sec. In each series, several series of puts() were performed: from 500 to 50,000 with step 1,000 (10 points for each series of wakeUpInterval). Following is the source that performs the whole cycle: http://www.powerdot.org/jbosscache-benchmark/JBossLRUTest.java And sample configuration for 5 seconds: http://www.powerdot.org/jbosscache-benchmark/treecache-5.xml You can, also, download the complete package with all the config files, JARs, Ant build script and run.bat from here: http://www.powerdot.org/jbosscache-benchmark/LRUTest.zip The memory settings used in the test were the same as in run.bat: -Xms 512M -Xmx 800M The machine used was single-processor Intel Pentium 4 2.6GHz with Hyperthreading enabled. Now the results. Following is all the series together: http://www.powerdot.org/jbosscache-benchmark/images/benchmark-all.gif As you can see not only time of put() is proportional of the number of objects (inneficient algorithm) but the coefficient of linear dependence increases drastically with the increase of wakeUpInterval. If you want to get a feeling of the "speed" you can, also, see the proportionally scaled graph of the same results: http://www.powerdot.org/jbosscache-benchmark/images/benchmark-all-propscale.gif As you can see - at 15 secs it is almost vertical! Please, also note the brown line representing the same test with LRU turned off - it is almost horizontal. Without LRU the cache performance, per se, is not bad - that if you can imagine a cache running without LRU in production, when JVM has hard limit of ~2GB on available memory :) Following is just the LRU-turned-off test: http://www.powerdot.org/jbosscache-benchmark/images/benchmark-lruOff.gif Then we did profiling to get some feeling of what is going wrong. Following are overall and zoomed-in snapshots: http://www.powerdot.org/jbosscache-benchmark/images/profiling.gif Diving into one of the slow branches: http://www.powerdot.org/jbosscache-benchmark/images/profiling-detail.gif These are just first-glance conclusions so may not be 100% the reson but this is what we think is wrong: 1. org.jboss.cache.Fqn class uses non-static logger, which means that its instance is created every time someone calls new Fqn() or clone(). 2. The toString() method in org.jboss.cache.Fqn is VERY slow (no surprise there: StringBuffer and other slow stuff is used). Odd, for us, is that org.jboss.cache.eviction.LRUPolicy uses code like Region region = regionManager_.getRegion(fqn.toString()); while Fqn can be used as a key in java.util.Map (?) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3839276#3839276 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3839276 ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
