-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Consider enabling low-level search cancellation by default #26258
Comments
I happen to have a testing environment already up and running (I was using it to test adaptive replica selection), I'll run the PMC benchmarks with and without low level cancellation and see what sort of difference it makes! |
Here are some benchmarks: LLC == "Low Level Cancellation". This was the PMC data set with the rate limited removed with 0 replicas, 5 primary shards, 5 data nodes with 31gb RAM and 16 CPUs, 1 client node with the same specs as the data nodes. All requests were sent to the client node. Benchmarks without throughput limiting:
Benchmarks with throughput limitingAnd here's the original benchmark that uses a capped 20 ops/s limiting
|
I'm ignoring the 99.9th and 100th percentiles which look a bit noisy, but otherwise the performance hit looks very low. |
So @dakrone ran a bunch more benchmarks for me and I crunched the search numbers. The differences were not statistically significant in most cases. The values that are statistically significantly different ( With Throttling EnabledInterestingly, all these values went down slightly with LLC enabled, although all 4-5% so maybe still noise?
With Throttling DisabledWith throttling disabled, it looks like there are some real effects on
|
Oh, and note this is |
Pinging @elastic/es-search-aggs |
One additional data point: Kibana is starting to think about using If the penalty feels too significant to enable low-level cancellation by default for all requests, another option could be to only enable it if an I'm adding the |
We discussed this issue in the search meeting, some points were made:
We agreed that a next step should be to run benchmarks again as this might have interesting interaction with changes to query execution now that we don't count all hits by default anymore. |
Related thought we had in this discussion: we should look into integrating |
Benchmarking on worst-case queries (max agg on match_all or popular-term query with large index) was not noticeably slower. Closes elastic#26258
Benchmarking on worst-case queries (max agg on match_all or popular-term query with large index) was not noticeably slower. Closes #26258
Benchmarking on worst-case queries (max agg on match_all or popular-term query with large index) was not noticeably slower. Closes elastic#26258
Benchmarking on worst-case queries (max agg on match_all or popular-term query with large index) was not noticeably slower. Closes elastic#26258
Low-level search cancellation is currently an opt-in, meaning that probably nobody is turning it on. Now that we reduced the overhead of low-level search cancellation (#25776), maybe we should investigate enabling it by default. We'd need to benchmark some cheap queries that match many documents to measure how much of an impact it has now.
cc @danielmitterdorfer
The text was updated successfully, but these errors were encountered: