amazon-web-services - S3 文档 : "one concurrent request per 85–90 MB/s of desired network throughput" -- Why?

Question

在下面链接的页面上，我发现了以下语句:

Make one concurrent request for each 85–90 MB/s of desired network throughput. To saturate a 10 Gb/s network interface card (NIC), you might use about 15 concurrent requests over separate connections. You can scale up the concurrent requests over more connections to saturate faster NICs, such as 25 Gb/s or 100 Gb/s NICs.

Performance Design Patterns for Amazon S3 - Horizontal Scaling and Request Parallelization for High Throughput

这些数字的来源是什么？我找不到任何其他证明这一点的文件。我的猜测是，此限制更多地说明了 EC2 实例而非 S3 上 NIC 的限制。不过，还有其他来源可以解释这些数字的来源吗？

需要明确的是，这不是关于如何优化 S3 吞吐量的问题——我知道有其他选择。这是关于 AWS S3 文档本身的问题。

Answer 1

唯一能够明确回答这个问题的人是那些从事 S3 内部工作的人。而且它们几乎肯定包含在 NDA 中。所以我要写的完全是猜测。

我们知道 S3 是分布式和冗余的:每个对象都存储在多个物理驱动器上，跨多个可用区。

我们可以从 S3 可作为网络服务这一事实推断出，在 S3 卷与外界之间存在某种形式的网络接口(interface)。很明显，是的，但是如果该网络接口(interface)被限制在 1Gbit/sec，它将能够实现大约 85-90 Mbyte/sec 的持续吞吐量。

同样重要的是要记住 AWS 使用软件定义的网络:因此虽然 S3 服务实际上可能有一个支持 10 Gbit/sec 的网络接口(interface)，但 AWS 可能会限制任何给定连接的可用带宽。

对我来说更有趣的是来自同一个链接的这句话:

we suggest making concurrent requests for byte ranges of an object at the granularity of 8–16 MB

这意味着冗余是在子对象级别管理的，因此一个大对象被分成多个可能 64 MB 的部分，并且这些部分是单独分布的。这是 how HDFS manages large files ，所以不是一个巨大的飞跃。

至于您假设它是 EC2 而不是 S3 的限制，我认为使用多个连接的建议排除了这一点。尽管 EC2 可能将单个连接限制为 1Gbit/sec，但我希望 S3 设计人员更关心他们系统上的负载。您始终可以通过在具有高带宽网络的两个 EC2 实例之间打开单个连接来测试它，看看它是否受到限制。