Skip to content

Avoid copies of large payloads #1529

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

Merged
merged 5 commits into from
Dec 8, 2022

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented Dec 7, 2022

Motivation:

Messages are prefixed with a 5-byte header. Currently messages of all sizes are written into a new buffer with their header. For smaller payloads this is good: we avoid the extra allocations associated with creating HTTP/2 frames. For large payloads the cost of the copy outweighs the cost of extra allocations.

Modifications:

  • For messages larger than 8KB emit an extra HTTP/2 DATA frame containing just the message header.

Result:

Better performance for large payloads.

@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Dec 7, 2022
Motivation:

Messages are prefixed with a 5-byte header. Currently messages of all
sizes are written into a new buffer with their header. For smaller
payloads this is good: we avoid the extra allocations associated with
creating HTTP/2 frames. For large payloads the cost of the copy
outweighs the cost of extra allocations.

Modifications:

- For messages larger than 8KB emit an extra HTTP/2 DATA frame
  containing just the message header.

Result:

Better performance for large payloads.
@glbrntt glbrntt force-pushed the gb-avoid-large-framing-copies branch from 5f26354 to 564f522 Compare December 7, 2022 12:24
} else if buffer.readableBytes > Self.singleBufferSizeLimit {
// Buffer is larger than the limit for emitting a single buffer: create a second buffer
// containing just the message header.
var prefixed = allocator.buffer(capacity: 5)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if we can be even cleverer with this and re-use the same fixed buffer.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done in f3f17a2

@glbrntt glbrntt merged commit 67788d5 into grpc:main Dec 8, 2022
@glbrntt glbrntt deleted the gb-avoid-large-framing-copies branch December 8, 2022 11:29
glbrntt added a commit to glbrntt/grpc-swift that referenced this pull request Jan 4, 2023
Motivation:

A change made in grpc#1529 allowed multiple DATA frames to be emitted for a
single message. One of the perf tests preconditions on there being
exactly one DATA frame per message which is no longer the case.

Modifications:

- Update the precondition

Result:

Perf test does not crash.
Lukasa added a commit that referenced this pull request Jan 4, 2023
Motivation:

A change made in #1529 allowed multiple DATA frames to be emitted for a
single message. One of the perf tests preconditions on there being
exactly one DATA frame per message which is no longer the case.

Modifications:

- Update the precondition

Result:

Perf test does not crash.

Co-authored-by: Cory Benfield <[email protected]>
WendellXY pushed a commit to sundayfun/grpc-swift that referenced this pull request Aug 24, 2023
Motivation:

Messages are prefixed with a 5-byte header. Currently messages of all
sizes are written into a new buffer with their header. For smaller
payloads this is good: we avoid the extra allocations associated with
creating HTTP/2 frames. For large payloads the cost of the copy
outweighs the cost of extra allocations.

Modifications:

- For messages larger than 8KB emit an extra HTTP/2 DATA frame
  containing just the message header.

Result:

Better performance for large payloads.
WendellXY pushed a commit to sundayfun/grpc-swift that referenced this pull request Aug 24, 2023
Motivation:

A change made in grpc#1529 allowed multiple DATA frames to be emitted for a
single message. One of the perf tests preconditions on there being
exactly one DATA frame per message which is no longer the case.

Modifications:

- Update the precondition

Result:

Perf test does not crash.

Co-authored-by: Cory Benfield <[email protected]>
pinlin168 pushed a commit to sundayfun/grpc-swift that referenced this pull request Aug 24, 2023
Motivation:

Messages are prefixed with a 5-byte header. Currently messages of all
sizes are written into a new buffer with their header. For smaller
payloads this is good: we avoid the extra allocations associated with
creating HTTP/2 frames. For large payloads the cost of the copy
outweighs the cost of extra allocations.

Modifications:

- For messages larger than 8KB emit an extra HTTP/2 DATA frame
  containing just the message header.

Result:

Better performance for large payloads.
pinlin168 pushed a commit to sundayfun/grpc-swift that referenced this pull request Aug 24, 2023
Motivation:

A change made in grpc#1529 allowed multiple DATA frames to be emitted for a
single message. One of the perf tests preconditions on there being
exactly one DATA frame per message which is no longer the case.

Modifications:

- Update the precondition

Result:

Perf test does not crash.

Co-authored-by: Cory Benfield <[email protected]>
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