rushgeo commented 2 months ago

Overview

What is the feature?

Adding performance measurement for the collections panel. The collections panel is populated by results from CMR, and is roughly 1/3 of the app as seen by the users. To most users, the app will not appear ready to use until these collection results are displayed (even though they can still do text searches).

What is the Solution?

Measure the time it takes to request the collections and render them into the app. Including the rendering time makes this distinct from the existing FINISHED_COLLECTIONS_TIMER event, which only includes the request time,and is displayed that in the footer of the app.

The collections rendering time is printed to the dev console. In the future, this performance metric will be sent to Google Analytics to measure real user performance. It is also tested by a GitHub action triggering the Playwright performance tests. In the future, these test results will be sent to Cloudwatch. The Playwright tests mock the CMR and GIBS requests, which could otherwise introduce variable response times into the performance metrics. By mocking those requests, this test should only measure the impact of our code changes on the rendering time.

What areas of the application does this impact?

State, Logging, e2e tests

Testing

Reproduction steps

Environment for testing: Any
Collection to test with: None

A developer server of EDSC (but not a deployed instance) will print to your browser's developer console a log message resembling:

[performance] Collections load time: 1842

See also that the performance GitHub action plan executed and the performance spec passed. The log of the performance test should include a lines for three browsers resembling:

[performance] Collections load time, chromium: 163 ms
[performance] Collections load time, firefox: 270 ms
[performance] Collections load time, webkit: 244 ms

Checklist

[x] I have added automated tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

codecov[bot] commented 2 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.90%. Comparing base (0f08eab) to head (7a0caa8). Report is 10 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1777 +/- ## =========================================== - Coverage 93.08% 67.90% -25.18% =========================================== Files 747 491 -256 Lines 18256 14486 -3770 Branches 4734 3983 -751 =========================================== - Hits 16993 9837 -7156 - Misses 1216 4329 +3113 - Partials 47 320 +273 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

rushgeo commented 2 months ago

Switched back to draft while I work on replacing console logs from the frontend and mocking requests to GIBS.

rushgeo commented 3 weeks ago

This has a test failing that doesn't make much sense - state is persisting between Jest tests. We're also not very excited about the actual method we've used to instrument the performance metrics. So I'll close this for now and we can revisit it later potentially with a different implementation.

This PR includes some changes to the two existing performance tests that may be worth spinning out into their own smaller PR.

nasa / earthdata-search

EDSC-4177: Implement performance metric: time to query and display collection results #1777