Skip to content
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

Improve the perceived performance of Discover #6599

Merged
merged 1 commit into from
Apr 24, 2024

Conversation

AMoo-Miki
Copy link
Collaborator

@AMoo-Miki AMoo-Miki commented Apr 22, 2024

Description

Removed the simultaneous rendering of DefaultDiscoverTable and DataGrid when only one would be displayed.
Bumped DOMPurify for a boost in performance.

Issues Resolved

Screenshot

2.13 - 10s span

  • Click to start of network call: 2392ms
  • Data to end of render: 5384ms
  • Click to end of render: 8016ms (network call 256ms)

2.13

PR - 10s span

  • Click to start of network call: 1289ms - 46% improvement
  • Data to end of render: 1626ms - 70% improvement
  • Click to end of render: 3186ms (network call 261ms) - 62% improvement

PRed

Changelog

  • feat: Improve the perceived performance of Discover when using the default tabular renderer

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

Copy link
Contributor

❌ Invalid Prefix For Manual Changeset Creation

Invalid description prefix. Found "feat". Only "skip" entry option is permitted for manual commit of changeset files.

If you were trying to skip the changelog entry, please use the "skip" entry option in the ##Changelog section of your PR description.

Copy link
Contributor

❌ Invalid Prefix For Manual Changeset Creation

Invalid description prefix. Found "feat". Only "skip" entry option is permitted for manual commit of changeset files.

If you were trying to skip the changelog entry, please use the "skip" entry option in the ##Changelog section of your PR description.

Copy link

codecov bot commented Apr 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.72%. Comparing base (d2d410b) to head (82dd4c3).
Report is 23 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #6599       +/-   ##
===========================================
+ Coverage   32.93%   67.72%   +34.79%     
===========================================
  Files        2260     3401     +1141     
  Lines       45769    66574    +20805     
  Branches     7200    10819     +3619     
===========================================
+ Hits        15075    45089    +30014     
+ Misses      29984    18850    -11134     
- Partials      710     2635     +1925     
Flag Coverage Δ
Linux_1 33.06% <ø> (+0.13%) ⬆️
Linux_2 55.65% <ø> (?)
Linux_3 45.21% <ø> (?)
Linux_4 34.95% <ø> (?)
Windows_1 33.08% <ø> (?)
Windows_2 55.62% <ø> (?)
Windows_3 45.21% <ø> (?)
Windows_4 34.95% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@AMoo-Miki AMoo-Miki force-pushed the discover-performance branch from 903eb14 to 2e2ddde Compare April 22, 2024 23:42
@ashwin-pc
Copy link
Member

@AMoo-Miki Can you add the changeset file?

@AMoo-Miki AMoo-Miki force-pushed the discover-performance branch from 2e2ddde to 82dd4c3 Compare April 23, 2024 17:18
Copy link
Member

@ashwin-pc ashwin-pc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I havent reviewed the data grid component because you plan on deprecating it anyways and is apparently the exact same code for now. The rest LGTM.

@ashwin-pc ashwin-pc merged commit b2c4b9c into opensearch-project:main Apr 24, 2024
67 checks passed
Copy link
Collaborator

@virajsanghvi virajsanghvi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free not to block on my comments

* SPDX-License-Identifier: Apache-2.0
*/

import './_data_grid_table.scss';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the css get imported twice or is it deduplicated? (not sure if the dedupe option is turned on for the loader)

Given this will be removed, feel free to ignore if this ends up having no real impact.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. The other one needs to go. Will add it to s subsequent PR.

const displayedColumns = getLegacyDisplayedColumns(
columns,
indexPattern,
hideTimeColumn,
isShortDots
);
const displayedColumnNames = displayedColumns.map((column) => column.name);
const pageSize = 50;
const [renderedRowCount, setRenderedRowCount] = useState(50); // Start with 50 rows
const pageSize = 10;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this an intended change in pageSize from previous behavior?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Being infinite-scrolled, 10 is nice balance between performance and initial view. In a future iteration, we will add lazy loading of the subsequent rows to make it even more unnoticeable.

// Current data grid loads 100 rows per page by default with inspect button and time range
await dashboardExpect.savedSearchRowCountFromLegacyTable(100);
// DefaultDiscoverTable loads 10 rows initially
await dashboardExpect.rowCountFromDefaultDiscoverTable(10);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: does it makes sense to export pageSize as a constant and use that here to avoid future updates?

Copy link
Collaborator Author

@AMoo-Miki AMoo-Miki Apr 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does. I will add that.

On second thought, when lazy-loading is added, depending on when the test attempts to count, we could have pageSize or greater than that. I will make this test act accordingly, using an exported value, to be future-safe.

@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch-Dashboards/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch-Dashboards/backport-2.x
# Create a new branch
git switch --create backport/backport-6599-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 b2c4b9c1b6128c2a0a20a54bd1865c47e4e0705a
# Push it to GitHub
git push --set-upstream origin backport/backport-6599-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch-Dashboards/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-6599-to-2.x.

@virajsanghvi
Copy link
Collaborator

One question regarding perf metrics: are those tracked somewhere? Just curious if there's a way of validating the expected gains hold in production builds.

@ruanyl
Copy link
Member

ruanyl commented Apr 24, 2024

@AMoo-Miki FYI, the auto backport failed, you may need to do it manually.

@kavilla
Copy link
Member

kavilla commented Apr 24, 2024

@ruanyl yes that is something that we need.

@AMoo-Miki
Copy link
Collaborator Author

are those tracked somewhere?

No but I intend to add code coverage and performance metrics gathering to my test framework.

Just curious if there's a way of validating the expected gains hold in production builds.

The graphs I placed above were from prod builds.

opensearch-trigger-bot bot pushed a commit that referenced this pull request Apr 25, 2024
Signed-off-by: Miki <[email protected]>
(cherry picked from commit b2c4b9c)
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
kavilla pushed a commit that referenced this pull request Apr 25, 2024
(cherry picked from commit b2c4b9c)

Signed-off-by: Miki <[email protected]>
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
LDrago27 pushed a commit to LDrago27/OpenSearch-Dashboards that referenced this pull request Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants