-
Notifications
You must be signed in to change notification settings - Fork 226
Adapt GetObject part size to the requested range #1584
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -77,7 +77,16 @@ impl S3CrtClient { | |
| .map_err(S3RequestError::construction_failure)?; | ||
|
|
||
| let mut options = message.into_options(S3Operation::GetObject); | ||
| options.part_size(self.inner.read_part_size as u64); | ||
|
|
||
| // Use the client read part size, or the requested range if smaller. | ||
| let part_size = (self.inner.read_part_size as u64).min( | ||
| params | ||
| .range | ||
| .as_ref() | ||
| .map(|range| range.end - range.start) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This means the Few questions:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Right.
That is not changed. We are still requesting
No changes either.
That's always been the case, but for writes we do not know the size in advance, so no trivial fix there.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We were already only requesting |
||
| .unwrap_or(u64::MAX), | ||
| ); | ||
| options.part_size(part_size); | ||
|
|
||
| let mut headers_sender = Some(event_sender.clone()); | ||
| let part_sender = event_sender.clone(); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -211,6 +211,7 @@ fn mount(args: CliArgs, client_builder: impl ClientBuilder) -> anyhow::Result<Fu | |
| // Set up a paged memory pool | ||
| let pool = PagedPool::new_with_candidate_sizes([ | ||
| args.cache_block_size_in_bytes() as usize, | ||
| mountpoint_s3_fs::s3::config::INITIAL_READ_WINDOW_SIZE, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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)?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only if
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh right, yes, makes sense |
||
| client_config.part_config.read_size_bytes, | ||
| client_config.part_config.write_size_bytes, | ||
| ]); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :(