lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aadithya C <>
Subject Re: Resizable LRUQueryCache
Date Tue, 10 Mar 2020 17:47:57 GMT
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 and
performance is already bad, resizing the cache will only help irrespective
of the workload. Additionally, we can also explore performance
optimizations for large evictions.
I can create a new derivative but I was wondering if this change can be
beneficial to other users and should be a part of lucene. One advantage of
being part of the LRUQueryCache is that this feature will evolve with other
cache changes.


On Thu, Mar 5, 2020 at 7:17 PM Atri Sharma <> wrote:

> 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 and exploratively resize the cache when faced with
> > memory pressure.
> >
> >
> > 2) With a resizable cache, we can control memory allocation dynamically
> > based on the workload. For a large cache, dropping the entire cache when
> we
> > want to reallocate some memory seems like an excessive action.
> >
> >
> > 3) The query cache effectiveness is very workload dependent. I have
> > observed the cache hit-rate can be in single digits for certain workloads
> > and memory can be effectively used elsewhere.
> When you say resizing, do you mean only increasing sizes or decreasing as
> well?
> IMO, this would require defining a model for on demand eviction until
> the cache reaches a target size (be mindful of what happens to
> incoming caching requests in that period). A potentially large
> downsizing request can lead to a large eviction time -- not sure what
> impact it would have on query performance.
> I would agree with Adrien's suggestion of using a new cache unless you
> have a very compelling reason not to. Even then, I would be wary of
> muddying LRUQueryCache's waters -- you might want to create your own
> custom derivative of it?
> Atri
> --
> Regards,
> Atri
> Apache Concerted
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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