在短时间内将大量文件上传到 GCP 存储桶时遇到瓶颈

Question

所以我有一个 GCP 存储桶，我必须将文件上传到它。问题是我有 1000 万个文件要上传到存储桶中（每个文件大小为 50kb），并且我的时间限制为 8 小时或更短。目前，我正在使用一个 Java 程序 (google ref code) 并在 1000 张图像上对其进行了测试，它在大约 300 毫秒内上传每个文件，但如果我使用多线程；我已经能够将平均时间减少到 40 毫秒（使用 20 个线程）。我最多可以使用 60 个线程并将时间进一步减少到 15-20 毫秒，但我也面临 3 个问题：

1. 每个文件 20 毫秒不够快。我需要它至少为 3 毫秒或更短。

2. 当我超过 25 个线程时，它会抛出“com.google.cloud.storage.StorageException: Connect timed out”异常。

3. 超过 60 个线程，程序似乎并没有变得更快（我猜是硬件限制）。

附加信息：

我的网速是 700Mbps 到 1.3 Gbps。我考虑过压缩和上传，但我们也有一些限制，所以不能使用这种方法。

提前致谢。

Answer 1

您可能在 Cloud Storage 上有一个热点。您无法查看this video，它解释了为什么以及如何解决该问题，即在您的文件名中添加一个哈希，在顺序序列之前。

Answer 2

所以我想通了。 guillaume blaquiere 的回答是有道理的，但这并没有解决我的问题。我的问题是有大量的小文件。为了提高性能，我做了以下工作：

1. 我制作了 1000 个文件的 zip（最后解释了 1000 个背后的逻辑），这使每个文件大约为 50-60 MB。这将我的数据集从 1000 万个文件减少到 10000 个文件。

2. 我使用 GSUtil 将文件上传到存储桶中，并使用了一个与存储桶绑定触发器的云功能来解压缩文件。由于云功能可以创建多个实例，因此它可以轻松处理多线程上传的处理。每次解压缩花费了我大约 40-50 秒，其中包括解压缩和其他一些操作。我假设只是解压缩需要 20-30 秒。

3. 取消注释并更改 .boto (/Users/UserName/.boto) 文件中的以下参数：

   parallel_composite_upload_threshold = 120

   parallel_composite_upload_component_size = 50M

为什么我使用 1000 个文件进行压缩：

parallel_composite_upload_component_size = 50M 表示上传的任何小于 50MB 的文件都不会被分解成块，并且 1000 个文件符合阈值。我已经对 1000,2000 和 5000 个文件 zip 进行了测试，并且所有这些文件都花费了相同的时间（而且在每种情况下，我的带宽都 100% 被使用；如果我有，每个时间差都可能是可见的更高的带宽）。至于为什么使用 50M 参数，是因为在测试时它最适合我们的用例。

结论：

在针对 10000 个 zip（1000 万个文件）测试此解决方案时，我发现它消耗了我的全部带宽，即 200 Mbps。上传时间约为 7 小时。