[ 
https://issues.apache.org/jira/browse/LUCENE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947500#comment-16947500
 ] 

Guoqiang Jiang edited comment on LUCENE-9002 at 10/9/19 9:51 AM:
-----------------------------------------------------------------

{code}
Atri wonders whether we should have different cost metris for synchronous and 
asynchronous caching.
{code}
When async caching is enabled, cache operation does not slow down queries, so 
we should cache as much as possible, which is beneficial to subsequent queries. 
When async caching is disabled, strict cache conditions are required because 
cache operation will slow down some queries.

I agree with him. If we can do all cache operation asynchronously in the 
future, it will be simpler and clearer.


was (Author: jgq2008303393):
{code}
Atri wonders whether we should have different cost metris for synchronous and 
asynchronous caching.
{code}
When async caching is enabled, cache operation does not slow down queries, so 
we should cache as much as possible, which is beneficial to subsequent queries. 
When async caching is disabled, strict cache conditions are required because 
cache operation will slow down some queries.

Now I agree with his consideration. If we can do all cache operation 
asynchronously in the future, it will be simpler and clearer.

> query caching leads to absurdly slow queries
> --------------------------------------------
>
>                 Key: LUCENE-9002
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9002
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/search
>    Affects Versions: 7.7.2, 8.2
>            Reporter: Guoqiang Jiang
>            Priority: Major
>              Labels: cache, performance
>
> *Description*
> We have dozens of ES clusters(based on Lucene) for metric scenarios. Most of 
> the queries are like this: _host_ip:10.10.10.10 AND timestamp:[2019-10-01 
> 00:00:00 TO 2019-10-05 23:59:59]_. And we frequently encounter some absurdly 
> slow queries.
> *Solution*
> For a long time range query(e.g. 5 days), each range query will consume tens 
> of megabytes of memory and spend hundreds of milliseconds to cache, but the 
> benefits are not obvious. And those large cache entries will cause frequent 
> cache eviction. So it's better to  skip the caching action directly when 
> large range query appears with a selective lead iterator.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to