-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Can match phase shard APM metric with search request context #137196
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
base: main
Are you sure you want to change the base?
Can match phase shard APM metric with search request context #137196
Conversation
- es.search.shards.phases.can_match.duration.histogram
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
|
Hi @chrisparrinello, I've created a changelog YAML for you. |
server/src/main/java/org/elasticsearch/index/search/stats/ShardSearchPhaseAPMMetrics.java
Outdated
Show resolved
Hide resolved
| responses.add(new CanMatchNodeResponse.ResponseOrFailure(canMatch(shardSearchRequest))); | ||
| indexShard.getSearchOperationListener().onCanMatchPhase(System.nanoTime() - shardCanMatchStartTimeInNanos); | ||
| indexShard.getSearchOperationListener() | ||
| .onCanMatchPhase(shardSearchRequest, System.nanoTime() - shardCanMatchStartTimeInNanos); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dove deeper at the overhead and I am thinking that we are wasting time reanalyzing the same search request over and over when many shards are allocated to the same data node.
Even if we create a new shard search request every time for the purpose of calling can match, the source is always the same, and so are the other arguments that are needed to extract the attributes. I would do that analysis only once for all the shards if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me. I'll update.
| canMatchPhaseMetric, | ||
| tookInNanos, | ||
| shardSearchRequest, | ||
| null // we don't have the time range filter info at this point in the search |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that getting the time range may be ok to do actually. We already collect it, but we just don't propagate it. I looked deeper at this and came up with #137314 . What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the other PR and I think taking advantage of that would require moving where we're recording this (the CanMatchContext hasn't been created yet) but I think based on our conversation on Wednesday about the coordinator level phase, we should be doing this anyway to cover all of the calls to canMatch (in the can-match phase, the query phase, etc.).
Add search request attributes context to: