Adapt GetObject part size to the requested range

[passaro]

Set the part size on GetObject requests to the requested range, if it is smaller than the client read part size. Since in this case the request will not be split in parts, the change only affects the way the CRT internally reserves the memory for the data to return.

Addresses an issue where the Prefetcher could cause higher peak memory usage with the unified memory pool compared to the previous approach (internal CRT pool + copy into a new buffer), since small requests would consume part-size buffers for longer.

Does this change impact existing behavior?

No functional changes.

Does this change need a changelog entry? Does it require a version change?

TODO: update client and fs

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

[mansi153]

This means the first_request_stream will always request the part size min(INITIAL_READ_WINDOW_SIZE, object_size), right?

Few questions:

• Is it the right understanding that the new logic also makes the splitting of metarequests more sensible, given we always start the second metarequest with range [INITIAL_READ_WINDOW_SIZE, end of object] (and not [PART_SIZE, end of object]) even though the first request has caused CRT to return up to part size?
• I believe this should also reduce the ttfb for the first read?
• Do we have this risk of blocked memory in writes too, and do we intend to make any changes there to reduce default part-size etc.?

[passaro]

This means the first_request_stream will always request the part size min(INITIAL_READ_WINDOW_SIZE, object_size), right?

Right.

Few questions:

• Is it the right understanding that the new logic also makes the splitting of metarequests more sensible, given we always start the second metarequest with range [INITIAL_READ_WINDOW_SIZE, end of object] (and not [PART_SIZE, end of object]) even though the first request has caused CRT to return up to part size?

That is not changed. We are still requesting INITIAL_READ_WINDOW_SIZE bytes as before, the only difference is that we also tell the CRT to use INITIAL_READ_WINDOW_SIZE as the part size.

• I believe this should also reduce the ttfb for the first read?

No changes either.

• Do we have this risk of blocked memory in writes too, and do we intend to make any changes there to reduce default part-size etc.?

That's always been the case, but for writes we do not know the size in advance, so no trivial fix there.

[mansi153]

That is not changed. We are still requesting INITIAL_READ_WINDOW_SIZE bytes as before, the only difference is that we also tell the CRT to use INITIAL_READ_WINDOW_SIZE as the part size.

Right! But won't this also change the S3 request range (and hence, size) now that we're requesting a 1.128M part instead of an 8M part? Previously we would receive data upto 8M offset but then re-request the 1.128M-8M range in the second meta request. Now we only receive 1.128M in the first go because it's the part size. So that is a change with this fix, no?

(^My comment about reduced ttfb was also based on this understanding, that smaller part GET => smaller S3 latency)

[passaro]

We were already only requesting INITIAL_READ_WINDOW_SIZE (1.125 MiB) before the change. read_part_size only comes into play for the buffer reservation, not for the data that is downloaded.

[mansi153]

Can we pls add a slightly more elaborate explanation of why we're doing this, for future context? The PR description is sufficient, however that sometimes gets lost when we refactor code for unrelated reasons :(

[mansi153]

For my understanding, this implies that for objects with [INITIAL_READ_WINDOW_SIZE < objects_size < read_part_size], we will still be using a peak memory of [INITIAL_READ_WINDOW_SIZE + part_size] right (because we advance the CRT backpressure window halfway through the first metarequest being read)?

[passaro]

Only if 2 * INITIAL_READ_WINDOW_SIZE <= object_size < read_part_size. What matters is the range on the second request, which will be object_size - INITIAL_READ_WINDOW_SIZE. If that is greater than INITIAL_READ_WINDOW_SIZE, it will require a full read_part_size buffer.

[mansi153]

Oh right, yes, makes sense

[passaro]

Closing this PR. The issue will be addressed on the CRT side (PR under review awslabs/aws-c-s3#563).