-
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 Solution] Optimize field formatting server side #130915
Conversation
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
@elasticmachine merge upstream |
@stephmilovic can you add more context about what you are optimizing and why? Maybe also describe other places in this bit of code that could be potentially slow and improved a la #129861 ? |
@kqualters-elastic Basically we were mapping over the fields twice when it can be done in one go. I combined the logic from formatFirstFields and formatSecondFields so now we are only mapping over each field once instead of twice. It's not a huge performance boost, but does cut down iteration in this part of the code by half |
@elasticmachine merge upstream |
const fields = await formatFirstFields(beatFields, responsesFieldSpec, indexesAlias); | ||
const secondFields = await formatSecondFields(fields); | ||
return secondFields; | ||
return formatFirstFields(beatFields, responsesFieldSpec, indexesAlias); |
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.
Quick question, what's the benefit of combining both of theses into one call?
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.
Ignore this. Saw the comment from Kevin above late. My bad ✋🏾
x-pack/plugins/timelines/server/search_strategy/index_fields/index.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/timelines/server/search_strategy/index_fields/index.ts
Outdated
Show resolved
Hide resolved
@elasticmachine merge upstream |
const fields = await formatFirstFields(beatFields, responsesFieldSpec, indexesAlias); | ||
const secondFields = await formatSecondFields(fields); | ||
return secondFields; | ||
return formatFirstFields(beatFields, responsesFieldSpec, indexesAlias); |
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 you can get rid of this and just call formatFirstFields
directly where needed. Only seems to be used in this file right now anyways.
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 don't think this is under the platform codeowners, but should it be under both? Would you consider it a part of sourcerer overall? If not, happy to leave it to @michaelolo24 :)
@stephmilovic, could you please include the codeowners file update to this PR?
I actually don't see this directory referenced in CODEOWNERS. Looking at the PR, it only pinged @elastic/security-threat-hunting-investigations. I think @yctercero might be confusing the ping from my other PR which is still awaiting platform review
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.
Testing that other one now! I'd just been going through the both of your open PRs. It seems like this deals with fetching the data views/fields, so I wondered if it was part of the larger data views architecture. If it's purely timeline and not an area of code platform needs to worry about, then all good 👍🏽
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.
Thanks so much for jumping into the performance stuff here, Steph! Pulled down and tested before and after with 27K fields. Like you already mentioned in your comments,
I didn't see a huge performance change but see the code is cleaner. Had a few notes going through it.
- Could we add some background to the PR description as to why we made this change, performance before/after? In case we somehow find we're slower we can go back and remember what our theory was in making a performance related change.
- I don't think this is under the platform codeowners, but should it be under both? Would you consider it a part of sourcerer overall? If not, happy to leave it to @michaelolo24 :)
- Since we're in this file, could we add docs to each of the functions in the file, giving a high level description of what each accomplishes? That could help in understanding which parts of the app they may affect.
@stephmilovic, could you please include the codeowners file update to this PR? |
💚 CLA has been signed |
cla/check |
b133c79
to
d68ab96
Compare
@yctercero done! |
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 - #131452 (Confirming we're merging this through the integration branch)
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💛 Build succeeded, but was flakyFailed CI StepsTest Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
⚪ Backport skippedThe pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually. Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
Summary
Server side field formatting optimization
Combines the two iterative functions that added
category
,description
, andindexes
(index alias) to each field. Optimization tested on 15k fields, async function runtime goes from ~700ms to ~300ms