Maybe start with your own cache implementation that implements a resize
method? The cache is pluggable through IndexSearcher.
Fully discarding the cache and swapping in a newly sized (empty) one could
also be jarring, so I can see the motivation for this method. Especially
for usages that are ho
Hi Atri,
Thanks for pointing out potential performance issues for high QPS workloads
when downsizing. Depending on the size of the cache, it might make sense to
create a new one with the necessary entries. On the other hand, if you
consider cases where the process is under heavy memory pressure an
On Fri, Mar 6, 2020 at 1:04 AM Aadithya C wrote:
>
> In my personal opinion, there are a few advantages of resizing -
>
>
> 1) The size of the cache is unpredictable as there is a fixed(guesstimate)
> accounting for the key size. With a resizable cache, we can potentially
> cache heavier queries a
In my personal opinion, there are a few advantages of resizing -
1) The size of the cache is unpredictable as there is a fixed(guesstimate)
accounting for the key size. With a resizable cache, we can potentially
cache heavier queries and exploratively resize the cache when faced with
memory press
Why do you need to resize it? And if you need to resize it, would it be
good enough to drop the old cache and start using a new one?
On Thu, Mar 5, 2020 at 12:54 AM Aadithya C wrote:
> Hi,
>
> We are looking at implementing a setter function to resize the
> LRUQueryCache on demand and evict the
