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.
Adithya On Thu, Mar 5, 2020 at 7:17 PM Atri Sharma <a...@apache.org> wrote: > On Fri, Mar 6, 2020 at 1:04 AM Aadithya C <aadithy...@gmail.com> 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: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
