CODEWITHSUNDEEP
ehcachespring-cache
Krishna
Krishna

Reputation: 7294

EHcache performance in using disk store cache

We are using the ehcache in our application. Look at the following configuration:

<diskStore path="java.io.tmpdir" />
<cache name="service" maxElementsInMemory="50000" eternal="true" overflowToDisk="true"/>

Since we have configured as eternal="true", Is it going to create caches for ever?. Is there a chance of running out of disk space?

What would be the performance impact on disk store?. It is definitely slower than the in-memory cache, but how much impact.

If more caches are stored in the disk, will it cause IO issue of doing multiple file operations?

Please suggest the best practice for a production grade applications. Consider that we have a 3 GB heap memory and 25000 concurrent users accessing the application. But, there is no database used in our application.

The application is deployed in WAS 8.5.5.

Upvotes: 0

Views: 1865

Answers (1)

Louis Jacomet
Louis Jacomet

Reputation: 14500

eternal=true means mappings will never expire.

overflowToDisk=true means that all mappings put in the cache will end up written on disk, from the first mapping put in the cache. The current Ehcache tiering model (since version 2.6.0) always makes use of the slower store - disk here - in order to give you predictable latency. When a mapping is accessed, it gets faulted into heap for faster retrieval. When too many mappings are faulted in heap, eviction from heap kicks in to keep the heap cache size according to maxElementsInMemory.

Given that you do not size the disk store by setting maxElementsLocalDisk, it defaults to 0 which means no limit. So yes, you may run out of disk space if you never explicitly remove cache entries.

It is quite hard to recommend proper cache size without knowing the details of your application. What I can recommend is that you measure both heap and disk usage and assess when the increased memory usage outweighs the performance gain.

Upvotes: 2

Related Questions