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

Log when active streams reaches and drops below max concurrent streams #974

Merged
merged 1 commit into from
Sep 25, 2020

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented Sep 25, 2020

Motivation:

Reaching max concurrent streams will cause frames on additional streams
to be buffered, and can therefore see increased latency. Observing this
is difficult.

Modifications:

  • Log any changes in HTTP/2 settings, not just the initial settings
  • Add a warning log when our active stream count matches max concurrent
    streams
  • Add a notice log when our stream count drops below max concurrent
    streams

Result:

Better observability when we get close to max concurrent streams.

@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Sep 25, 2020
@glbrntt glbrntt requested a review from Lukasa September 25, 2020 12:42
Copy link
Collaborator

@Lukasa Lukasa left a comment

Choose a reason for hiding this comment

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

One note about calculating max concurrent streams.

}, uniquingKeysWith: { a, _ in a })
)

let maxConcurrentStreams = settings.first(where: { $0.parameter == .maxConcurrentStreams })
Copy link
Collaborator

Choose a reason for hiding this comment

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

A quick FYI: if there are multiple instances of a setting in a HTTP/2 settings frame, the last instance of the setting is the one that counts. HTTP2Settings is a RandomAccessCollection so you can do reversed() for free.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, good catch. Thanks!

Motivation:

Reaching max concurrent streams will cause frames on additional streams
to be buffered, and can therefore see increased latency. Observing this
is difficult.

Modifications:

- Log any changes in HTTP/2 settings, not just the initial settings
- Add a warning log when our active stream count matches max concurrent
  streams
- Add a notice log when our stream count drops below max concurrent
  streams

Result:

Better observability when we get close to max concurrent streams.
@glbrntt glbrntt force-pushed the gb-warn-on-max-streams-limit branch from 9eb424d to ac1116c Compare September 25, 2020 14:45
@glbrntt glbrntt merged commit 5e0d712 into grpc:main Sep 25, 2020
@glbrntt glbrntt deleted the gb-warn-on-max-streams-limit branch September 25, 2020 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants