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

optimize number of buffer allocations #11879

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

panchenko
Copy link
Contributor

@panchenko panchenko commented Feb 4, 2025

Currently this improves 2 flows

  1. Known length message which length is greater than 1Mb
    previously the first buffer was 1Mb, and then many buffers of 4096 bytes (from CodedOutputStream), now subsequent buffers are also up to 1Mb

  2. in case of compression, the first write is always 10 bytes buffer (gzip header), but worth allocating more space

@@ -27,9 +27,6 @@
*/
class OkHttpWritableBufferAllocator implements WritableBufferAllocator {

// Use 4k as our minimum buffer size.
private static final int MIN_BUFFER = 4096;
Copy link
Member

Choose a reason for hiding this comment

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

Okio Buffer works quite differently than Netty. Okio uses Segments that are all the same size and then combines adjacent buffers to avoid excessive internal fragmentation. We should leave this in-place and actually set it to 8192.

Copy link
Member

Choose a reason for hiding this comment

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

(If we were more serious, we'd round up: (capacityHint + 8191) / 8192 * 8192.)

@panchenko panchenko changed the title okhttp: remove 4096 min buffer size optimize number of buffer allocations Feb 8, 2025
@ejona86
Copy link
Member

ejona86 commented Feb 10, 2025

I think I see what you're trying to do, but I'm not sure this is how we want to do it. You've basically realized that we needed the minimum allocation size for unknown message sizes/compression. It seems we should quickly revert the Netty/Servlet changes, since those are known to cause regressions. And I need to stare at this more.

CC @shivaspeaks

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 10, 2025
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Feb 10, 2025
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.

3 participants