嘿，有一些类似的问题，但是没有一个完全像这样，而且很多问题已经存在多年了并且过时了。
我在服务器上编写了一些代码，该代码通过boto3方法upload_file使用密钥将jpeg照片上传到s3存储桶。最初，这看起来很棒。这是将文件上传到s3的超级简单的解决方案。
问题是，我有用户。我的用户正在通过电话应用程序将其jpeg发送到我的服务器。虽然我承认我可以生成预先签名的上传URL并将其发送到电话应用程序，但这将需要大量重写电话应用程序和API。
所以我只希望电话应用程序将照片发送到服务器。然后，我想将照片从服务器发送到s3。我实现了它，但是它太慢了。我不能要求我的用户容忍那些缓慢的上传。
我该怎么做才能加快速度？
我在Google上进行了一些搜索，发现了以下内容：https://medium.com/@alejandro.millan.frias/optimizing-transfer-throughput-of-small-files-to-amazon-s3-or-anywhere-really-301dca4472a5
这表明解决方案是增加TCP / IP连接的数量。更多的TCP / IP连接意味着上传速度更快。
好的，很好！
我该怎么做？如何增加TCP / IP连接的数量，以便可以更快地将单个jpeg上传到AWS s3？
请帮助。
答案 0 :(得分：2)
具有讽刺意味的是，我们{@ {1}}和boto3都使用了多年，我们都喜欢。
但是我们经常想知道为什么awscli的awscli或aws s3 cp --recursive往往比尝试通过aws s3 sync进行大量上传（甚至使用{{1}）要快得多}的boto3或concurrent.futures（而且您甚至都不敢在您的工作人员之间共享相同的ThreadPoolExecutor：在the docs中被警告，这是有充分理由的；讨厌的）最终将在最不方便的时间发生崩溃。
最后，我咬住了子弹头，看了awscli在ProcessPoolExecutor之上引入的“自定义”代码。
基于这一小小的探索，这是一种通过使用s3.Bucket中内置的并发性将许多文件上传到S3的方法，不仅适用于单个大文件的可能多个部分，而且以及一堆各种大小的文件。据我所知，该功能并未通过boto3文档中介绍的boto3.s3.transfer的更高级别的API公开。
以下内容：
使用boto3创建一个boto3，例如awscli的boto3.s3.transfer使用的那个。
将最大线程数扩展为20。
增强TransferManager用来匹配的基础aws s3 sync最大池连接容量（默认情况下，它最多使用10个连接）。
为您提供了可选的回调功能（此处带有urllib3进度条，但您当然可以拥有所需的任何回调）。
速度 （超过100MB / s，在ec2实例上测试）。
我提出了一个完整的示例，如要旨here，其中包括生成500个随机的csv文件，总计约360MB。但是，如果您假设Aready在下面的botocore中有一堆文件，总共tqdm个字节：
filelist