Don't retry flushing CloudWatch metrics

[jennmills]

Description

The pwa-kit-runtime is a project that allows us to run Node applications on the Managed Runtime. Inside this project we build an Express server that interfaces with AWS lambda. As our runtime is invoked, we send various metrics to Cloudfront to be displayed in various dashboards before we call the lambdas callback to ultimately send a response to the requesting client (the browser). Before we call this callback we make sure that any metrics we gathered are sent to Cloudfront.

One caveat is that the Cloudfront api endpoint is rate limited, meaning that in times of extreme load a request might be denied. The way our application works, we will retry the sending of metrics multiple times (read below how that works). This causes slow response times.

We shouldn't do this as it's more important to respond to clients requests than it is to send off metrics that we hardly use.

Details

The API for flushing metrics is rate limited and in high load environments, we have seen this cause performance issues when waiting for the call to finish and retry if it fails.

Every retry it waits 50 milliseconds plus an additional 25 milliseconds for the next retry which can add up.

This PR includes changes to reduce the retries to 0 - effectively removing the retries so that the API does not cause performance issues.

Future Considerations

We should look to solve this in a better way. If possible perform the metric sending after making the callback call. This may or may no be possible as the lambda might be destroyed at this time. But its worth looking to how we can do this.

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

As mentioned above we have reduced retries to 0 instead of 3 when flushing CloudWatch Metrics fail meaning it will only attempt the API call once.

How to Test-Drive This PR

After merging this PR the PWA Kit SDK Team will need to do a Release Preview (FYI @bendvc). When the Release Preview is ready to go we can reach out to the LWR team to test the changes.

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

[olibrook]

Brian Buchanan on the LWR team re-ran performance test with Jen's changes. His findings:

Prior to the change we saw ~1.3s avg duration at scale. We are down to ~400ms with the change. 400ms is still 4x the SSR Render Time metric. (Granted this can be inaccurate with the change)

They have a dashboard, here, too.

What a first PR @jennmills – wowie! 🥳

[olibrook]

These tests are unrelated to the changes in the PR, but dropping the retry logic in the metrics code caused our branch coverage to drop. I decided to add more tests somewhere else, instead of dropping the coverage requirement.

The metrics code itself has 100% test and branch coverage.

[kevinxh]

Thanks for keeping up the test coverage!