[Performance][Security Solution][2/4] - Timeline Performance#212478
Merged
michaelolo24 merged 6 commits intoelastic:mainfrom Mar 11, 2025
Merged
[Performance][Security Solution][2/4] - Timeline Performance#212478michaelolo24 merged 6 commits intoelastic:mainfrom
michaelolo24 merged 6 commits intoelastic:mainfrom
Conversation
michaelolo24
added
release_note:skip
michaelolo24
force-pushed
the
security-performance-timeline
branch
from
222a79a to
594807c
Compare
Contributor
|
Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations) |
michaelolo24
force-pushed
the
security-performance-timeline
branch
from
2576a0c to
c358526
Compare
logeekal
reviewed
Mar 6, 2025
Contributor
logeekal
left a comment
logeekal
left a comment
There was a problem hiding this comment.
Done code review as of now. Will post the results of Desk Testing soon.
Contributor
There was a problem hiding this comment.
might result in error somewhere since it is a 2D array and previously eventsPerPage[0] was [] and with this change it is undefined
Contributor
Author
There was a problem hiding this comment.
It's only accessed on line 597, which would only be doing empty work to flatten a nested empty array. Happy to revert it, but not sure if it's necessary
...y/plugins/security_solution/public/timelines/components/timeline/tabs/on_demand_renderer.tsx
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Since this component is not in itself related to React.suspense, I would suggest renaming it to TimelineTabFallback
...y/plugins/security_solution/public/timelines/components/timeline/tabs/on_demand_renderer.tsx
Outdated
Show resolved
Hide resolved
...y/plugins/security_solution/public/timelines/components/timeline/tabs/on_demand_renderer.tsx
Outdated
Show resolved
Hide resolved
...gins/security_solution/public/timelines/components/timeline/tabs/on_demand_renderer.test.tsx
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Do you think we need to remove similar useEffect in query and eql tab so there it does not override the effect of this useEffect 🤷
Contributor
Author
There was a problem hiding this comment.
Potentially, but it should be aligned with the query tab as they should be running the same query string. I don't expect this change to be necessary
Contributor
There was a problem hiding this comment.
Are you planning to remove that OutPortal InPortal stuff as well in this PR?
Contributor
Author
There was a problem hiding this comment.
No, I wasn't planning on making that change in this PR
michaelolo24
force-pushed
the
security-performance-timeline
branch
2 times, most recently
from
7536190 to
e3c8e54
Compare
logeekal
reviewed
Mar 7, 2025
Contributor
logeekal
left a comment
logeekal
left a comment
There was a problem hiding this comment.
Desk Testing looks good. Below are couple of observations:
Timeline Search Strategy firing twice
When there is a timeline bottom bar, timelineSearchStrategy is firing twice to get the count of events, everytime. See demo below:
timelineSearchStrategy_firing_twice.mp4
App Perf with 500K total fields
I tried app performance with 500K total fields with :
- one document having all 500K fields populated
- around 10K docs with 25K fields populated
the whole app feels slow specially because useInitSourcerer takes around 10s to finish and get all the fields when visiting Alerts Page. a
Below URL took 12s to resolve and that essential blocks whole Alerts page. And app also seems slow. Not sure why.
http://localhost:5601/internal/data_views/fields?pattern=.alerts-security.alerts-default%2Capm-*-transaction*%2Cauditbeat-*%2Cendgame-*%2Cfilebeat-*%2Clogs-*%2Cpacketbeat-*%2Ctest*%2Ctraces-apm*%2Cwinlogbeat-*%2C-*elastic-cloud-logs-*&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score&meta_fields=_ignored&allow_no_index=true&apiVersion=1
Screen.Recording.2025-03-07.at.12.31.40.mov
Contributor
|
One more feedback. it looks like this PR introduces a wierd space in timeline as highlighted below. for comparison, i have posted a screenshot from Release-sec instance. 
|
michaelolo24
added
ci:cloud-deploy
Contributor
Author
|
@logeekal - Can you retest, I was unable to replicate the duplicate queries...and the gap is from the borealis changes as that is also currently on main, but not 8.18 |
michaelolo24
force-pushed
the
security-performance-timeline
branch
from
d1c290b to
c81c4a5
Compare
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
History
|
logeekal
approved these changes
Mar 10, 2025
Contributor
logeekal
left a comment
logeekal
left a comment
There was a problem hiding this comment.
Can you retest, I was unable to replicate the duplicate queries...and the gap is from the borealis changes as that is also currently on main, but not 8.18
@michaelolo24 , I retested and can confirm that now only single query is firing. I also noticed that gap is only in light theme and not in borealis 🤦 .
Thanks for making these changes.
michaelolo24
added a commit
that referenced
this pull request
Mar 20, 2025
…212478) (#213988) # Backport This will backport the following commits from `main` to `8.17`: - [[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":"michael.olorunnisola@elastic.co"},"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","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":["8.17"],"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,"state":"NOT_CREATED"}]}] BACKPORT-->
Contributor
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
1 similar comment
Contributor
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
CAWilson94
pushed a commit
to CAWilson94/kibana
that referenced
this pull request
Mar 22, 2025
…#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
This was referenced Mar 24, 2025
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Mar 24, 2025
…#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)
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":"michael.olorunnisola@elastic.co"},"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-->
kibanamachine
removed
the
backport missing
Contributor
|
This PR didn't land on time for the latest 8.17.4 BC. Updating the labels. |
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Apr 7, 2025
…#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/solutions/security/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Apr 7, 2025
…#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/solutions/security/plugins/security_solution/public/timelines/components/timeline/index.tsx # x-pack/solutions/security/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Jun 6, 2025
…#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/solutions/security/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Jun 6, 2025
…#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/solutions/security/plugins/security_solution/public/timelines/components/timeline/index.tsx # x-pack/solutions/security/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
michaelolo24
added a commit
to michaelolo24/kibana
that referenced
this pull request
Jun 6, 2025
…#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/solutions/security/plugins/security_solution/public/timelines/components/timeline/unified_components/index.tsx
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
michaelolo24
added a commit
that referenced
this pull request
Jun 6, 2025
…212478) (#222987) # Backport This will backport the following commits from `main` to `8.18`: - [[Performance][Security Solution][2/4] - Timeline Performance (#212478)](#212478) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Michael Olorunnisola","email":"michael.olorunnisola@elastic.co"},"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","Team:Threat Hunting:Investigations","ci:cloud-deploy","ci:project-redeploy","backport:version","v9.1.0","v8.19.0","v8.17.5"],"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/215791","number":215791,"state":"MERGED","mergeCommit":{"sha":"45922ffa0196328ccb715fa2f2af1cc9d0fae139","message":"[8.x] [Performance][Security Solution][2/4] - Timeline Performance (#212478) (#215791)\n\n# Backport\n\nThis will backport the following commits from `main` to `8.x`:\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"}},{"branch":"8.17","label":"v8.17.5","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"}},{"url":"https://github.com/elastic/kibana/pull/217362","number":217362,"branch":"9.0","state":"OPEN"},{"url":"https://github.com/elastic/kibana/pull/217364","number":217364,"branch":"8.18","state":"OPEN"}]}] BACKPORT-->
michaelolo24
added a commit
that referenced
this pull request
Jun 6, 2025
…212478) (#222989) # Backport This will backport the following commits from `main` to `9.0`: - [[Performance][Security Solution][2/4] - Timeline Performance (#212478)](#212478) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Michael Olorunnisola","email":"michael.olorunnisola@elastic.co"},"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","Team:Threat Hunting:Investigations","ci:cloud-deploy","ci:project-redeploy","backport:version","v9.1.0","v8.19.0","v8.17.5"],"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/215791","number":215791,"state":"MERGED","mergeCommit":{"sha":"45922ffa0196328ccb715fa2f2af1cc9d0fae139","message":"[8.x] [Performance][Security Solution][2/4] - Timeline Performance (#212478) (#215791)\n\n# Backport\n\nThis will backport the following commits from `main` to `8.x`:\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"}},{"branch":"8.17","label":"v8.17.5","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"}},{"url":"https://github.com/elastic/kibana/pull/222987","number":222987,"branch":"8.18","state":"OPEN"}]}] BACKPORT-->
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Summary
Part 2 of #212173
Testing
For setup see testing section here: #212173 (comment)
Areas/How to test:
fieldsapi 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 theuseInitSourcerercallfieldsapi fire on first interaction with the tabBackground
When investigating the performance of the security solution application, one of the issues that was observed was queries to the
fieldsapi 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 relevantdataViewnecessary 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.
First the
withDataViewHOC was removed as it was only used in 2 components that shared a parent - child relationship, and the childUnifiedTimelinewas only used in the parent. The hook that HOC calls was not caching the dataView being created, sodataView.createwas being called up to 6 times unnecessarily. Now it is only called once in each tab.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.
Additional checks were added to the
useTimelineEventshook to limit additional re-renders caused by unnecessary reference changes when the underlying values never actually changeChecklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
Identify risks