-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Security Solutions] Improves query performance of first and last events #91790
[Security Solutions] Improves query performance of first and last events #91790
Conversation
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
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.
way faster results 🚀 looks good
firstSeen: get('firstSeen.value_as_string', aggregations), | ||
lastSeen: get('lastSeen.value_as_string', aggregations), | ||
}; | ||
if (options.order === 'asc') { |
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.
nice fix with the double query
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.
LGTM. Thanks!
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…nts (elastic#91790) ## Summary Fixes performance issues and timeouts with first and last events. Previously we were using aggregations and max/min but that is slower in orders of magnitude vs. using sorting + size: 1 + track_total_hits: false. This PR also splits out the aggregate of first/last into two separate calls as we were calling the same aggregate twice for first/last twice rather than calling one query for first even and a second query for last event which is also faster when you don't use an aggregate even if you ran them multiple times back to back compared to using aggregates for min/max's. For how we determined performance numbers quantifiably and how we did profiling see this comment: elastic#91269 (comment) Shoutout to @dplumlee for the help and the first cut and draft of this PR that I morphed into this PR. For any manual testing, please test: * Hosts overview page and look at "last events" * Network overview page and look at "last events" * "last events" on the timeline * Host details page the first and last seen event for a particular host. The more records the better. * Network details page and the first and last seen for a particular network. 127.0.0.1 is good as that has a lot of records. For qualitative viewing you should see a noticeable difference like so where the first seen/last seen/last events show up quicker on detailed pages from the left side compared to the right side:  ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…nts (#91790) (#91797) ## Summary Fixes performance issues and timeouts with first and last events. Previously we were using aggregations and max/min but that is slower in orders of magnitude vs. using sorting + size: 1 + track_total_hits: false. This PR also splits out the aggregate of first/last into two separate calls as we were calling the same aggregate twice for first/last twice rather than calling one query for first even and a second query for last event which is also faster when you don't use an aggregate even if you ran them multiple times back to back compared to using aggregates for min/max's. For how we determined performance numbers quantifiably and how we did profiling see this comment: #91269 (comment) Shoutout to @dplumlee for the help and the first cut and draft of this PR that I morphed into this PR. For any manual testing, please test: * Hosts overview page and look at "last events" * Network overview page and look at "last events" * "last events" on the timeline * Host details page the first and last seen event for a particular host. The more records the better. * Network details page and the first and last seen for a particular network. 127.0.0.1 is good as that has a lot of records. For qualitative viewing you should see a noticeable difference like so where the first seen/last seen/last events show up quicker on detailed pages from the left side compared to the right side:  ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
Summary
Fixes performance issues and timeouts with first and last events. Previously we were using aggregations and max/min but that is slower in orders of magnitude vs. using sorting + size: 1 + track_total_hits: false. This PR also splits out the aggregate of first/last into two separate calls as we were calling the same aggregate twice for first/last twice rather than calling one query for first even and a second query for last event which is also faster when you don't use an aggregate even if you ran them multiple times back to back compared to using aggregates for min/max's.
For how we determined performance numbers quantifiably and how we did profiling see this comment:
#91269 (comment)
Shoutout to @dplumlee for the help and the first cut and draft of this PR that I morphed into this PR.
For any manual testing, please test:
For qualitative viewing you should see a noticeable difference like so where the first seen/last seen/last events show up quicker on detailed pages from the left side compared to the right side:

Checklist
Delete any items that are not applicable to this PR.