在短时间内将大量文件上传到 GCP 存储桶时遇到瓶颈
Bottleneck while uploading lots of files to GCP bucket in a small time
所以我有一个 GCP 存储桶，我必须向它上传文件。问题是我有 1000 万个文件要上传到存储桶中（每个文件大小为 50kb）并且时间限制为 8 小时或更短。目前，我正在使用 Java 程序 (google ref code) 并在 1000 张图像上对其进行测试，它在大约 300 毫秒内上传每个文件，但如果我使用多线程；我已经能够将平均时间减少到 40 毫秒（使用 20 个线程）。我最多可以使用 60 个线程并将时间进一步减少到 15-20 毫秒，但我也面临 3 个问题：
每个文件 20 毫秒不够快。我需要它至少为 3 毫秒或更少。
当我超过 25 个线程时抛出“com.google.cloud.storage.StorageException：连接超时”异常。
超过 60 个线程，程序似乎并没有变得更快（我猜是硬件限制）。
附加信息：
我的网速是 700Mbps 到 1.3Gbps。我考虑过压缩和上传，但我们在这方面也有一些限制，所以不能使用那种方法。
提前致谢。
您可能在云存储上有一个热点。您无法查看 this video 来解释问题的原因和解决方法，即在文件名中的顺序序列之前添加哈希。
所以我想通了。 guillaume blaquiere 的回答是有道理的，但这并没有解决我的问题。我的问题是有大量的小文件。为了提高性能，我做了以下事情：
我压缩了 1000 个文件（最后解释了 1000 个文件背后的逻辑），这使得每个文件大约为 50-60 MB。这将我的数据集从 1000 万个文件减少到 10000 个文件。
我使用 GSUtil 将文件上传到存储桶中，并使用具有绑定到存储桶的触发器的云功能来解压缩文件。由于云函数可以创建多个实例，因此它可以轻松处理多线程上传的处理。每次解压缩大约需要 40-50 秒，其中包括解压缩和其他一些操作。我假设仅解压缩将花费 20-30 秒之间的时间。
取消注释并更改 .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 个小时。
所以我有一个 GCP 存储桶，我必须向它上传文件。问题是我有 1000 万个文件要上传到存储桶中（每个文件大小为 50kb）并且时间限制为 8 小时或更短。目前，我正在使用 Java 程序 (google ref code) 并在 1000 张图像上对其进行测试，它在大约 300 毫秒内上传每个文件，但如果我使用多线程；我已经能够将平均时间减少到 40 毫秒（使用 20 个线程）。我最多可以使用 60 个线程并将时间进一步减少到 15-20 毫秒，但我也面临 3 个问题：
每个文件 20 毫秒不够快。我需要它至少为 3 毫秒或更少。
当我超过 25 个线程时抛出“com.google.cloud.storage.StorageException：连接超时”异常。
超过 60 个线程，程序似乎并没有变得更快（我猜是硬件限制）。
附加信息：
我的网速是 700Mbps 到 1.3Gbps。我考虑过压缩和上传，但我们在这方面也有一些限制，所以不能使用那种方法。
提前致谢。
您可能在云存储上有一个热点。您无法查看 this video 来解释问题的原因和解决方法，即在文件名中的顺序序列之前添加哈希。
所以我想通了。 guillaume blaquiere 的回答是有道理的，但这并没有解决我的问题。我的问题是有大量的小文件。为了提高性能，我做了以下事情：
我压缩了 1000 个文件（最后解释了 1000 个文件背后的逻辑），这使得每个文件大约为 50-60 MB。这将我的数据集从 1000 万个文件减少到 10000 个文件。
我使用 GSUtil 将文件上传到存储桶中，并使用具有绑定到存储桶的触发器的云功能来解压缩文件。由于云函数可以创建多个实例，因此它可以轻松处理多线程上传的处理。每次解压缩大约需要 40-50 秒，其中包括解压缩和其他一些操作。我假设仅解压缩将花费 20-30 秒之间的时间。
取消注释并更改 .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 个小时。