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

Prevent fetching the user agent concurrently #1205

Merged
merged 1 commit into from
Jul 28, 2021

Conversation

richardm-stripe
Copy link
Contributor

@richardm-stripe richardm-stripe commented Jul 28, 2021

r? @dcr-stripe
cc @stripe/api-libraries

Motivation

Fixes #1202

Summary

Right now, when calculating the proper user agent, we check a cache and shell out to uname if the cache is empty. This is bad because we can shell out to uname multiple times concurrently before the cache is populated. For some bulk operation usage patterns this causes an unwanted CPU spike (see #1202). It would be better to only shell out once.

This PR makes two changes:

  1. Makes the cache use a promise. Promises are very good at resolving a value only once.
  2. Caches the result of uname directly, instead of the derived user_agent. This allows me to remove some questionable cache invalidation. We should only ever need to call uname once, uname is not expected to change.

Breakingness:

Stripe.USER_AGENT_SERIALIZED isn't marked as private, but I think we should consider it safe to just remove this property. It was an internal cache and I cannot imagine any legitimate use case relying on it.

Tests

Existing tests for getClientUserAgent pass.

Copy link
Contributor

@dcr-stripe dcr-stripe left a comment

Choose a reason for hiding this comment

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

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Spawning process for every parallel request results in high CPU usage
2 participants