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

Adaptive Read Buffer #1708

Closed
seanmonstar opened this issue Nov 16, 2018 · 0 comments
Closed

Adaptive Read Buffer #1708

seanmonstar opened this issue Nov 16, 2018 · 0 comments
Labels
A-http1 Area: HTTP/1 specific. C-performance Category: performance. This is making existing behavior go faster. E-medium Effort: medium. Some knowledge of how hyper internal works would be useful.

Comments

@seanmonstar
Copy link
Member

Add an adaptive read buffer strategy for proto::h1::io::Buffered, such that the size of the read buffer changes depending on the amount of bytes that are found on the transport for each read operation. This concept is similar to Netty's AdaptiveRecvByteBufAllocator.

  • After a read on the transport, the number of bytes read should be compared with the current guess size.
    • If the number of bytes is significantly less, the guess should be lowered.
    • If the number of bytes is significantly more, the guess should raised.
  • It should likely make use of "steps". Something like starting at 1024 and doubling each step is probably a good start.
  • If the bytes read stays within the current step, no adjustment is needed.
@seanmonstar seanmonstar added C-performance Category: performance. This is making existing behavior go faster. E-medium Effort: medium. Some knowledge of how hyper internal works would be useful. A-http1 Area: HTTP/1 specific. labels Nov 16, 2018
seanmonstar added a commit that referenced this issue Nov 28, 2018
The default read strategy for HTTP/1 connections is now adaptive. It
increases or decreases the size of the read buffer depending on the
number of bytes that are received in a `read` call. If a transport
continuously fills the read buffer, it will continue to grow (up to the
`max_buf_size`), allowing for reading faster. If the transport
consistently only fills a portion of the read buffer, it will be shrunk.

This doesn't provide much benefit to small requests/responses, but
benchmarks show it to be a noticeable improvement to throughput when
streaming larger bodies.

Closes #1708
seanmonstar added a commit that referenced this issue Nov 28, 2018
The default read strategy for HTTP/1 connections is now adaptive. It
increases or decreases the size of the read buffer depending on the
number of bytes that are received in a `read` call. If a transport
continuously fills the read buffer, it will continue to grow (up to the
`max_buf_size`), allowing for reading faster. If the transport
consistently only fills a portion of the read buffer, it will be shrunk.

This doesn't provide much benefit to small requests/responses, but
benchmarks show it to be a noticeable improvement to throughput when
streaming larger bodies.

Closes #1708
seanmonstar added a commit that referenced this issue Nov 28, 2018
The default read strategy for HTTP/1 connections is now adaptive. It
increases or decreases the size of the read buffer depending on the
number of bytes that are received in a `read` call. If a transport
continuously fills the read buffer, it will continue to grow (up to the
`max_buf_size`), allowing for reading faster. If the transport
consistently only fills a portion of the read buffer, it will be shrunk.

This doesn't provide much benefit to small requests/responses, but
benchmarks show it to be a noticeable improvement to throughput when
streaming larger bodies.

Closes #1708
seanmonstar added a commit that referenced this issue Nov 28, 2018
The default read strategy for HTTP/1 connections is now adaptive. It
increases or decreases the size of the read buffer depending on the
number of bytes that are received in a `read` call. If a transport
continuously fills the read buffer, it will continue to grow (up to the
`max_buf_size`), allowing for reading faster. If the transport
consistently only fills a portion of the read buffer, it will be shrunk.

This doesn't provide much benefit to small requests/responses, but
benchmarks show it to be a noticeable improvement to throughput when
streaming larger bodies.

Closes #1708
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-http1 Area: HTTP/1 specific. C-performance Category: performance. This is making existing behavior go faster. E-medium Effort: medium. Some knowledge of how hyper internal works would be useful.
Projects
None yet
Development

No branches or pull requests

1 participant