You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SingleUploadThreshold config paramter is introduced. (#66)
The S3 client's **multipart_upload** boolean flag did not give users control over when to use single vs. multipart upload. Additionally, the BOSH HTTP client was using **CreateDefaultClient**, which doesn't reuse TCP connections, resulting in higher latency under concurrent upload/download workloads.
Solution - Single upload threshold:
Replaced the multipart_upload flag with a new **single_upload_threshold** config parameter (bytes). Files at or below this size use a single PutObject call; larger files use multipart upload. The value is capped at **5GB** to respect the AWS S3 hard limit. For GCS, which requires single put for all uploads but has no size limit, the threshold is automatically set to [math.MaxInt64]
Keep-alive HTTP client:
Replaced **CreateDefaultClient** with **CreateKeepAliveDefaultClient**. Benchmark tests showed this reduces response time for concurrent uploads/downloads by reusing existing TCP connections.
"multipart_copy_threshold": <int64> (optional - default: 5368709120), # 5 GB - files larger than this use multipart copy
32
+
"multipart_copy_part_size": <int64> (optional - default: 104857600), # 100 MB - must be at least 5 MB
33
+
"single_upload_threshold": <int64> (optional - default: 0) # bytes; files <= this use a single PutObject call, larger files use multipart upload. 0 means always use multipart. Max 5 GB for AWS S3. GCS ignores this and always uses single upload.
34
34
}
35
35
```
36
-
> Note: **multipart_upload** is not supported by Google - it's automatically set to false by parsing the provided 'host'
0 commit comments