Eviction for type memory is different than type count

I would like to use Infinispan as a cache for binary image data (Java type byte[] ). I believe that the default Infinispan strategy is LIFO or a similar strategy that prefers to store the last used / added cache object.

In my loadtest script, I make four calls in a round to retrieve the given object. The first call is supposed to never hit the cache (because each round a unique object is requested), but the next three always go to the cache. Thus, the expected profile is as follows:

 #1: MISS-HIT-HIT-HIT #2: MISS-HIT-HIT-HIT ... 

It works great when I configure Infinispan with a COUNT drop type with some objects:

 <local-cache name="imagesCache" statistics="true"> <!-- lifespan="30 min" max-idle="30 min" interval="1 min" --> <expiration lifespan="1800000" max-idle="1800000" interval="60000" /> <memory> <binary eviction="COUNT" size="500" /> </memory> </local-cache> 

Statistics show the exact hit of 3/4 cache at the end of the run (as well as in the middle): JMX cache statistics for type COUNT in the middle

Cache hit rate based on the numbers I captured in loadtest: (2952-738)/2952 = 0.75

When I change the number of objects to store in memory ( <binary eviction="COUNT" size="100" /> ), the beat ratio does not change (as expected).

During the run, I measured the heap size before and after the load test (measurements taken after several GC calls), and it turns out that 500 objects occupy about 114.895.000 - 62.445.000 = 52.450.000 bytes = about 100 KB per entity: Cache heap statistics for type COUNT at the end

After that, I restarted the application with just this slight cache configuration change:

 <memory> <binary eviction="MEMORY" size="1000000" /> </memory> 

I would expect that the Infinispan performance would have the same profile, but it turns out that after the specified amount of memory is fully allocated, newly added objects will not evict old objects, but will be immediately evicted. This means that after about 100 objects have been added, all four requests are for caching the result cache. It can be seen that now the ratio is 0.58 instead of 0.75: Cache Heap Statistics for the MEMORY Type at the End

Cache Hit Ratio: (2952-738-504)/2952 = 0.579

If I increase the memory, indeed, the hit ratio is close to 0.75, but I would like the hit rate to be the same regardless of the size of the memory (provided that the memory can fit in at least several objects).

As soon as I configure passivation to the file, the memory-based eviction policy will start working as expected:

 <local-cache name="imagesCache" statistics="true"> <expiration lifespan="1800000" max-idle="1800000" interval="60000" /> <persistence passivation="true"> <file-store path="/var/cache/infinispan" purge="true"> <write-behind thread-pool-size="5" /> </file-store> </persistence> <memory> <binary eviction="MEMORY" size="1000000" /> </memory> </local-cache> 

enter image description here

Passivation → Attributes show that the number of liabilities is 1121 (equal to the number of evictions) and Activation → Attributes show that the number of activations is 1242. This means that some objects were activated several times (and immediately evicted, which is not good). In general, I expect the number of activations to be zero.

Any idea how to set up a eviction policy based on memory so that the cache hit rate is the same as for a count-based policy?

Topics I read relatively above (they don't have a direct answer to the above question):

+5
source share

Source: https://habr.com/ru/post/1274923/


All Articles