Do not cache profiled search requests

[polyfractal]

Today, profiled search requests are eligible for request caching, which can lead to some very confusing situations (fast took time but slow profile results because the results are being served by the cache). Profiling should never really be cached at all because of the nature of profiling.

Related, ProfileWeight delegates isCacheable() to the wrapped query, but I wonder if we should perhaps return false to prevent the profiled query from affecting Lucene's caching statistics?

[elasticmachine]

Pinging @elastic/es-search-aggs

[iverase]

@polyfractal I have just opened an issue with the opposite case (slow tookand fast profile) , the question is if profiling should use the cache at all?

[polyfractal]

Hiya @iverase, sorry for the delay.

I may be missing the distinction between the two issues, but that was my intention with this one: do not cache the profile response in the Elasticsearch query cache (to prevent results from being served from cache), and try to prevent Lucene from caching the query components by flagging the whole thing as not-cacheable.

I probably just explained myself poorly in the first post :) I agree... we should prevent profiling from being affected by various caches as much as possible since it makes comparisons difficult.

[iverase]

I see three cases:

1. query is profiled and shows a slow execution time. Then it is executed outside the profiler and it has a fast took because it is is served by the cache (this case).
2. The opposite is possible. You run a query and has a fairly big took. Then you profile it and it shows a fast profile because it is profiling the query served by the cache.
3. It is possible even to run the profiler to the same query twice and the results being totally different (2nd is served by the cache).

My point is that maybe the profiler should never see the queries served by the cache nor those queries being put on the cache. A fancy addition would be to mark the parts of the query which are sensitive for caching.

[silbertmonaphia]

Is there any progress? get same issue(case 3) while profiling es query

[polyfractal]

Hi @silbertmonaphia, there is a (just-opened) PR that I believe will fix this issue: #48195

[polyfractal]

Closed by #48195