[jboss-user] [JBossCache] - Re: Problem using FileCacheLoader

genman: Sorry, I missed the trace in the log file: main org.jboss.cache.loader.jdbm.JdbmCacheLoader - JDBM database /tmp/cacheStore/TreeCache-Cluster opened with 11134 entries. Does that mean all the 11134 entries had been Physically loaded in memory? It seemed only take 7 seconds -- was the time reasonable ? The reason for the doubt was also because the GET performance SLOWED down pretty much after I restart the Cache. The test case was as following: 1. In a for loop, right after I PUT an entry, I call a GET on the same node with same key to make sure the entry saved successfully. 2. In step 1 each GET took average time about 5-10 ms. 3. After PUT about 11K entries (diff key/value under one node). I stop the service and restart the Cache (currently it hosted on Weblogic AS so I acturally restarted the Weblogic AS). And I hope the cache would pre-load the 11K entries in memory from the persistent file in the startup. 4. Then I GET the entry again. But this time it was much slower -- each took about 70-100ms. So it seemed to me the object may not really found in the memory. Could you please take a look for the setting and log, and check whether I missed anything ? Besides, in our current business requirement, we actually need to write/read a lot data to cache in a Burst mode, so we pretty concern about the cache write/read performance but not care too much how it persist. When write to cache most of the data are new, and when read from the cache if the data not in Cache memory it won't be in the file either (We prefer cache all data in mem without expiration). Could you please suggest the best configuration for it ? Also considering the tree structure, if I store the data under multiple node instead one, will that improve the read/write performance ? Thank you very much ! -Bruce View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957970#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...