Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cache or not details to profile api output #20108

Closed
ppf2 opened this issue Aug 22, 2016 · 5 comments
Closed

Add cache or not details to profile api output #20108

ppf2 opened this issue Aug 22, 2016 · 5 comments
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories

Comments

@ppf2
Copy link
Member

ppf2 commented Aug 22, 2016

Elasticsearch version: 2.3

Describe the feature:

While the query cache in 2.x makes decisions automatically on what to cache and what not to cache, it does not rewrite queries automatically to improve cache-ability. It will be useful to include caching details as part of the profile api output to indicate which clauses are being cached vs. not cached. This will be helpful additional diagnostic information to have, for some of queries with not cached clauses may not end up showing up in the hot threads (and there is not a way to examine the cached entries or the entires that were part of the history of entries).

@makeyang
Copy link
Contributor

+1

@polyfractal
Copy link
Contributor

I just had a skim through the code to see how difficult this would be. I think it'll be relatively non-trivial. The cache is instantiated as a shared, per-node resource (even though it tracks queries on a per-shard basis). So we can't "wrap" the cache with an instrumented profiler like we can with queries, since it will be concurrently servicing non-profiled queries too.

The API is a bit tricky too; caching the queries is a side-effect of creating the weight... the caller doesn't know if the filter was actually cached or not.

There may be a way to wrap the CachingWeightWrapper with an instrumented profiler, which immediately asks for the various cache stats (size, hitCount, etc) and uses that to approximate if the filter was cached or not. It'd only be a guess though. Other, concurrent queries could have been caching at the same time in unrelated non-profiled queries.

Dunno. I'll corner @jpountz in Prague and see what he thinks :)

@sundarv85
Copy link

+1

This is definitely a very valuable feature esp when debugging complex caching issues. Currently in our stack, we have indexes with 200 Million documents and aggregation response takes somewhere between 4-60 seconds. Debugging such issue is too complicated. When profile API can respond back if the response comes from cache or not, such information could be very helpful.

@colings86 colings86 added the :Search/Search Search-related issues that do not fall into other categories label Apr 24, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@ppf2
Copy link
Member Author

ppf2 commented Mar 3, 2020

Starting in 7.6, profile API now disables the query and request cache when
profile is set to true (#48195) so users will not have to deal with figuring out if the profile API output is reflecting query performance with/without request/query caching in play, etc..

@ppf2 ppf2 closed this as completed Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories
Projects
None yet
Development

No branches or pull requests

7 participants