在执行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的互联网连接，距离我经常使用的最远的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不会导致进一步的收益。如果我增加到max_concurrent_requests一个荒谬的值，我将使连接饱和超出可靠性，并且数据包丢失将导致错误，重试，重传和其他低效率-因此，我可以增加多少并获得回报的收益将逐渐减少有利。

独立地，增加存储空间multipart_chunksize往往会提高我的性能，降低存储性能会降低性能，但这只是在很小的程度上，因为与实际传输数据相比，multipart_chunksize我将按比例花费更少或更多的时间进行内务处理-因此，如果我的连接数量较大，则效果会更好快速干净。如果我的连接速度慢且容易出错，那将变得更糟。分段上传可以从失败的部分上传中恢复，但是硬故障后的最小重传单位是multipart_chunksize-因此，较大的值会增加我必须重传的数量，以便从硬错误中恢复。（这是指完全失败的部分请求，而不是TCP重传，它当然要小得多。）

total_object_size max_concurrent_requests，和之间存在明确的交互作用multipart_chunksize。

最小的“有趣”参数是multipart_threshold，它是甚至采用多部分机制的对象大小：小于的对象multipart_threshold将不使用多部分。在快速，干净的连接上，建议增加此值，但超出某个阈值，则较大的值表示传输速度较慢，因为这将意味着我们不使用多部分允许的并列主义。

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

对于2 TB的文件，multipart_threshold它没有影响，因为对于总大小超过5 GB的对象，必须进行分段。

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