[8.17] [Performance][Security Solution][2/4] - Timeline Performance (#212478) #213988
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#212478) ## Summary Part 2 of elastic#212173 ### Testing For setup see testing section here: elastic#212173 (comment) **Areas/How to test:** - For the following pages, test there are no `fields` api requests in the inspector network tab when visiting from another page. IF YOU REFRESH on any of these pages, you will see these requests as they are called by the Query Search Bar and the `useInitSourcerer` call - Cases Page - Dashboard Page - Timelines Page - Timeline - All Tabs - Does it show the loading screen on first interaction? - Does the `fields` api fire on first interaction with the tab - When you navigate back to those tabs, do they not re-render? - All other pages hosting timeline - Do you feel like the performance is generally better? ### Background When investigating the performance of the security solution application, one of the issues that was observed was queries to the `fields` api on pages that had no reason making that request (such as Cases, or the Dashboards list view). This was due to the background background loaded tabs of timeline loading the relevant `dataView` necessary for their search functionality. When the fields request is significantly large this can have a massive impact on the experience of users on pages that should be relatively responsive. To fix this a few changes were made. 1. First the `withDataView` HOC was removed as it was only used in 2 components that shared a parent - child relationship, and the child `UnifiedTimeline` was only used in the parent. The hook that HOC calls was not caching the dataView being created, so `dataView.create` was being called up to 6 times unnecessarily. Now it is only called once in each tab. 2. A new wrapper `OnDemandRenderer` (open to different naming 😅) was created that will not render any of the nested tabs until they are opened. Once they are opened, they stay in memory, to avoid re-calling expensive api's every time a user switches tabs. _Note_: There is currently a known issue where navigating between various routes in security solution causes the whole application to unmount and re-mount. Which means every page change will lead to timeline needing to be re-loaded when the tab is opened. This is being resolved in a separate effort. 3. Additional checks were added to the `useTimelineEvents` hook to limit additional re-renders caused by unnecessary reference changes when the underlying values never actually change ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 ### Identify risks (cherry picked from commit 2d8f3c1) # Conflicts: # x-pack/plugins/security_solution/public/timelines/components/timeline/context.ts # x-pack/plugins/security_solution/public/timelines/components/timeline/index.tsx # x-pack/plugins/security_solution/public/timelines/components/timeline/tabs/index.tsx # x-pack/plugins/security_solution/public/timelines/components/timeline/tabs/lazy_timeline_tab_renderer.test.tsx # x-pack/plugins/security_solution/public/timelines/components/timeline/tabs/lazy_timeline_tab_renderer.tsx # x-pack/plugins/security_solution/public/timelines/components/timeline/tabs/query/events_count.tsx # x-pack/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
1 task
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
History
|
PhilippeOberti
approved these changes
Mar 20, 2025
michaelolo24
added a commit
that referenced
this pull request
Mar 24, 2025
…212478) (#215791) # Backport This will backport the following commits from `main` to `8.x`: - [[Performance][Security Solution][2/4] - Timeline Performance (#212478)](#212478) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Michael Olorunnisola","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-03-11T16:56:45Z","message":"[Performance][Security Solution][2/4] - Timeline Performance (#212478)\n\n## Summary\nPart 2 of https://github.com/elastic/kibana/pull/212173\n\n### Testing\nFor setup see testing section here:\nhttps://github.com//pull/212173#issue-2870522020\n\n**Areas/How to test:**\n- For the following pages, test there are no `fields` api requests in\nthe inspector network tab when visiting from another page. IF YOU\nREFRESH on any of these pages, you will see these requests as they are\ncalled by the Query Search Bar and the `useInitSourcerer` call\n - Cases Page\n - Dashboard Page\n - Timelines Page\n- Timeline\n - All Tabs\n - Does it show the loading screen on first interaction?\n - Does the `fields` api fire on first interaction with the tab\n - When you navigate back to those tabs, do they not re-render?\n- All other pages hosting timeline\n - Do you feel like the performance is generally better?\n\n\n### Background\n\nWhen investigating the performance of the security solution application,\none of the issues that was observed was queries to the `fields` api on\npages that had no reason making that request (such as Cases, or the\nDashboards list view). This was due to the background background loaded\ntabs of timeline loading the relevant `dataView` necessary for their\nsearch functionality. When the fields request is significantly large\nthis can have a massive impact on the experience of users on pages that\nshould be relatively responsive.\n\nTo fix this a few changes were made. \n\n1. First the `withDataView` HOC was removed as it was only used in 2\ncomponents that shared a parent - child relationship, and the child\n`UnifiedTimeline` was only used in the parent. The hook that HOC calls\nwas not caching the dataView being created, so `dataView.create` was\nbeing called up to 6 times unnecessarily. Now it is only called once in\neach tab.\n\n2. A new wrapper `OnDemandRenderer` (open to different naming 😅) was\ncreated that will not render any of the nested tabs until they are\nopened. Once they are opened, they stay in memory, to avoid re-calling\nexpensive api's every time a user switches tabs.\n_Note_: There is currently a known issue where navigating between\nvarious routes in security solution causes the whole application to\nunmount and re-mount. Which means every page change will lead to\ntimeline needing to be re-loaded when the tab is opened. This is being\nresolved in a separate effort.\n\n3. Additional checks were added to the `useTimelineEvents` hook to limit\nadditional re-renders caused by unnecessary reference changes when the\nunderlying values never actually change\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n### Identify risks","sha":"2d8f3c1544aa6bff74623273a278f580df0d918d","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport missing","Team:Threat Hunting:Investigations","ci:cloud-deploy","ci:project-redeploy","backport:version","v9.1.0","v8.19.0","v8.17.4"],"title":"[Performance][Security Solution][2/4] - Timeline Performance","number":212478,"url":"https://github.com/elastic/kibana/pull/212478","mergeCommit":{"message":"[Performance][Security Solution][2/4] - Timeline Performance (#212478)\n\n## Summary\nPart 2 of https://github.com/elastic/kibana/pull/212173\n\n### Testing\nFor setup see testing section here:\nhttps://github.com//pull/212173#issue-2870522020\n\n**Areas/How to test:**\n- For the following pages, test there are no `fields` api requests in\nthe inspector network tab when visiting from another page. IF YOU\nREFRESH on any of these pages, you will see these requests as they are\ncalled by the Query Search Bar and the `useInitSourcerer` call\n - Cases Page\n - Dashboard Page\n - Timelines Page\n- Timeline\n - All Tabs\n - Does it show the loading screen on first interaction?\n - Does the `fields` api fire on first interaction with the tab\n - When you navigate back to those tabs, do they not re-render?\n- All other pages hosting timeline\n - Do you feel like the performance is generally better?\n\n\n### Background\n\nWhen investigating the performance of the security solution application,\none of the issues that was observed was queries to the `fields` api on\npages that had no reason making that request (such as Cases, or the\nDashboards list view). This was due to the background background loaded\ntabs of timeline loading the relevant `dataView` necessary for their\nsearch functionality. When the fields request is significantly large\nthis can have a massive impact on the experience of users on pages that\nshould be relatively responsive.\n\nTo fix this a few changes were made. \n\n1. First the `withDataView` HOC was removed as it was only used in 2\ncomponents that shared a parent - child relationship, and the child\n`UnifiedTimeline` was only used in the parent. The hook that HOC calls\nwas not caching the dataView being created, so `dataView.create` was\nbeing called up to 6 times unnecessarily. Now it is only called once in\neach tab.\n\n2. A new wrapper `OnDemandRenderer` (open to different naming 😅) was\ncreated that will not render any of the nested tabs until they are\nopened. Once they are opened, they stay in memory, to avoid re-calling\nexpensive api's every time a user switches tabs.\n_Note_: There is currently a known issue where navigating between\nvarious routes in security solution causes the whole application to\nunmount and re-mount. Which means every page change will lead to\ntimeline needing to be re-loaded when the tab is opened. This is being\nresolved in a separate effort.\n\n3. Additional checks were added to the `useTimelineEvents` hook to limit\nadditional re-renders caused by unnecessary reference changes when the\nunderlying values never actually change\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n### Identify risks","sha":"2d8f3c1544aa6bff74623273a278f580df0d918d"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/212478","number":212478,"mergeCommit":{"message":"[Performance][Security Solution][2/4] - Timeline Performance (#212478)\n\n## Summary\nPart 2 of https://github.com/elastic/kibana/pull/212173\n\n### Testing\nFor setup see testing section here:\nhttps://github.com//pull/212173#issue-2870522020\n\n**Areas/How to test:**\n- For the following pages, test there are no `fields` api requests in\nthe inspector network tab when visiting from another page. IF YOU\nREFRESH on any of these pages, you will see these requests as they are\ncalled by the Query Search Bar and the `useInitSourcerer` call\n - Cases Page\n - Dashboard Page\n - Timelines Page\n- Timeline\n - All Tabs\n - Does it show the loading screen on first interaction?\n - Does the `fields` api fire on first interaction with the tab\n - When you navigate back to those tabs, do they not re-render?\n- All other pages hosting timeline\n - Do you feel like the performance is generally better?\n\n\n### Background\n\nWhen investigating the performance of the security solution application,\none of the issues that was observed was queries to the `fields` api on\npages that had no reason making that request (such as Cases, or the\nDashboards list view). This was due to the background background loaded\ntabs of timeline loading the relevant `dataView` necessary for their\nsearch functionality. When the fields request is significantly large\nthis can have a massive impact on the experience of users on pages that\nshould be relatively responsive.\n\nTo fix this a few changes were made. \n\n1. First the `withDataView` HOC was removed as it was only used in 2\ncomponents that shared a parent - child relationship, and the child\n`UnifiedTimeline` was only used in the parent. The hook that HOC calls\nwas not caching the dataView being created, so `dataView.create` was\nbeing called up to 6 times unnecessarily. Now it is only called once in\neach tab.\n\n2. A new wrapper `OnDemandRenderer` (open to different naming 😅) was\ncreated that will not render any of the nested tabs until they are\nopened. Once they are opened, they stay in memory, to avoid re-calling\nexpensive api's every time a user switches tabs.\n_Note_: There is currently a known issue where navigating between\nvarious routes in security solution causes the whole application to\nunmount and re-mount. Which means every page change will lead to\ntimeline needing to be re-loaded when the tab is opened. This is being\nresolved in a separate effort.\n\n3. Additional checks were added to the `useTimelineEvents` hook to limit\nadditional re-renders caused by unnecessary reference changes when the\nunderlying values never actually change\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n### Identify risks","sha":"2d8f3c1544aa6bff74623273a278f580df0d918d"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/213978","number":213978,"state":"OPEN"},{"branch":"8.17","label":"v8.17.4","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/213988","number":213988,"state":"MERGED","mergeCommit":{"sha":"3febe25204eaf1c83970a7010ef63ac1d3fa8431","message":"[8.17] [Performance][Security Solution][2/4] - Timeline Performance (#212478) (#213988)\n\n# Backport\n\nThis will backport the following commits from `main` to `8.17`:\n- [[Performance][Security Solution][2/4] - Timeline Performance\n(#212478)](https://github.com/elastic/kibana/pull/212478)\n\n\n\n### Questions ?\nPlease refer to the [Backport tool\ndocumentation](https://github.com/sorenlouv/backport)\n\n"}}]}] BACKPORT-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This will backport the following commits from
mainto8.17:Questions ?
Please refer to the Backport tool documentation