amazon-web-services - 执行 S3 分段上传时 multipart_threshold 和 mutilpart_chunksize 的最佳设置是什么

Question

是否有任何公式可用于确定 multipart_threshold 和 mutilpart_chunksize 的最佳设置？假设如果我尝试使用分段上传在 S3 中上传 2 TB 文件，那么阈值和块大小的最佳值是多少。任何使用多部分上传/下载的脚本将不胜感激。

Answer 1

没有单一的最佳设置。最佳值取决于许多因素，包括运行 aws-cli 的系统与相关 S3 区域之间的延迟和可用带宽、机器上的 CPU 和网络容量以及对象的大小.

对于某些场景，无论配置如何，整体性能都可能没有显着差异。

也许比您询问的任何一个参数更重要的是 max_concurrent_requests .这默认为 10。

我有一个 100 Mbit/s 的 Internet 连接，距离我经常使用的最远的 S3 区域有 80 毫秒。有趣的是，我可以告诉你，我可以以每部分大约 5 Mbit/s 的速度上传到这个区域，所以默认情况下，默认设置下我的最佳性能约为 50 Mbit/s (5 Mbit/s × max_concurrent_requests --您的里程可能会有很大差异，5 Mbit/s 仅用于说明目的)。

如果我增加 max_concurrent_requests我将近似线性地提高我的网络传输速度，直到我最大化资源(最有可能是我的 100 Mbit/s 连接)。然而，增加max_concurrent_requests超过 total_upload_size ÷ multipart_chunksize不会带来进一步的 yield 。如果我增加 max_concurrent_requests到一个大得离谱的值，我会使我的连接饱和，超出可靠性，丢包会导​​致错误、重试、重传和其他低效率——因此，我可以增加多少并让它有益的返回递减。

独立增加 multipart_chunksize将倾向于提高我的性能并降低它会降低这一点，但只会在很小的程度上降低，因为与实际传输数据相比，我会按比例减少或更多的时间花在内部管理上——
所以更大 multipart_chunksize如果我的连接快速干净会更好。如果我的连接速度慢且容易出错，情况会更糟。分段上传可以从失败的分段上传中恢复，但硬故障后的最小重传单位为multipart_chunksize -- 因此，较大的值会增加我必须重新传输的数量，以便从硬错误中恢复。 (这是指完全失败的部分请求，而不是 TCP 重传，后者当然要小得多。)

total_object_size、max_concurrent_requests之间有明显的交互作用, 和 multipart_chunksize .

最不“有趣”的参数是 multipart_threshold ，这是多部分机制甚至参与的对象大小:小于 multipart_threshold 的对象不会使用多部分。在快速、干净的连接上，增加这个值可能是可取的，但超过某个阈值，更大的值将意味着更慢的传输，因为这意味着我们不使用 multipart 允许的并行性。

对于 2 TB 文件，任何值 multipart_chunksize低于 200 MB 将没有意义，因为 multipart 要求单个文件上传不超过 10,000 个不同的部分，而 200 MB × 10,000 是 2 TB。较小的值实际上可能无效并导致错误，除非 aws-cli 静默覆盖您的规范并使用较大的值，因为 10,000 部分的最大值是由 S3 服务本身强加的。未经测试。

对于 2 TB 文件，multipart_threshold没有影响，因为 multipart 对于总大小超过 5 GB 的对象是强制性的。

对于 2 TB 文件，max_concurrent_requests应该设置为您的连接可以维持的最高值，以获得最佳吞吐量。您将需要一种机制来监控您的带宽使用情况，以便将其调整为最佳值。