jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "vinay b" <vybe3...@gmail.com>
Subject Re: what happened to my cache keys
Date Mon, 21 Jul 2008 18:16:16 GMT
Thanks, that worked!! I still had to use a periodic sleep to allow cleanup
to catchup but now I can insert large number of objects (500,000) without
running out of heap space.

I still have the issue with the <cachename>.key file being zero'd out at the
end of data access (using the same configuration, and calling the dispose
method at the end of the program).

Now here's the next question. what kind of read performance can I expect
using JCS. Using the same cache file created above (500,000 records) , I end
up taking about 35 seconds for every 10,000 reads (presumably from disk I/O)
. Thats about 285 reads per second . Seems slow to me. Is there anyway of
speeding this up, GIVEN that I'm starting from a persistent FILE.

Keep in mind that this rate seems to slow down, the larger the number of
records in the cache file.

Thanks for all the help.

On Mon, Jul 21, 2008 at 10:16 AM, Dennis Jacobs <djacobs@esurg.com> wrote:

> I'm using JCS to accomplish something similar (I believe).  Try
> configuring the cache region (memory) with:
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> This will force the write out to disk when putting items in the cache,
> instead of waiting for a shutdown.  In order to get the keys written out as
> well I shutdown the cache.  I've had some trouble getting it to shutdown
> gracefully if it needs to do a lot of cleanup (large disk optimizations or
> serialization from the memory cache); by using the UPDATE option to write
> to
> disk during puts this keeps the shutdown quick and tidy.
> There's probably an api which you could call in code to write out keys as
> well without shutting down, but I haven't tried it.  Once the keys are
> written out you can just copy the .key and .data files to any number of
> target machines.
> Best of luck,
> Dennis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message