boto3/aiobotocore上传S3被限速？如何提速至接近AWS CLI水平？

核心问题根因 #

你当前的实现和AWS CLI出现几十倍的性能差距，本质是没有对齐S3官方的高性能传输机制，存在几个关键配置偏差：

• 直接调用put_object本身就绕开了SDK内置的传输优化层：put_object是单请求全量上传模式，大文件会作为单一连续TCP流发送，没有任何分片、并发、独立重试优化，完全不符合S3大对象上传的最佳实践。
• 即便使用了upload_fileobj，大多也因为SDK默认配置过于保守，没有达到和AWS CLI同等的传输能力：默认的连接池大小、重试模式、分片参数都和AWS CLI的生产级配置存在量级差异。
• 你观察到的“初始速度正常、后续突然骤降”现象，本质是触发了SDK默认的传统指数退避逻辑：单连接长传大对象时一旦遇到网络波动、服务端临时限流，SDK会主动暂停传输等待退避计时，表现就是速度断崖式下跌，和AWS CLI的分片独立重试逻辑完全不同。
• 异步场景下aiobotocore客户端的默认连接池大小配置过低，即便开启了并发分片，也会被硬限制最大并发请求数，跑不满可用带宽。

可落地的优化方案（可完全对齐AWS CLI性能） #

1. 替换原有的put_object调用，配置和AWS CLI对齐的传输参数 #

S3的高性能核心逻辑是多部分并行上传，AWS CLI本身就是基于boto3的传输层实现的，只要把配置调整到和AWS CLI一致的水平，就能拿到同等的上传速度，不需要手动实现分片逻辑。
具体参考配置：

# 同步boto3场景
import io
from boto3 import client
from botocore.config import Config
from boto3.s3.transfer import TransferConfig

# 传输层配置：完全对齐AWS CLI的默认优化参数
s3_transfer_config = TransferConfig(
    multipart_threshold=8 * 1024 * 1024,  # 8MB以上的对象自动切分为多部分上传
    multipart_chunksize=16 * 1024 * 1024, # 每个分片固定16MB大小，避免分片数过多触发API限流
    max_concurrency=10,  # 单文件最多10个并行分片传输
    use_threads=True,
)

# 客户端连接配置：匹配上面的并发数
s3_client = client(
    "s3",
    config=Config(
        max_pool_connections=20,  # 提升连接池大小，匹配并发分片需求（默认值仅10）
        retries={
            "max_attempts": 3,
            "mode": "adaptive"  # 用自适应重试替代传统指数退避，避免传输中途硬暂停
        }
    )
)

# 直接上传内存中的压缩数据，无需落盘
s3_client.upload_fileobj(
    Fileobj=io.BytesIO(compressed_data),
    Bucket=target_bucket,
    Key=target_object_key,
    Config=s3_transfer_config,
    ExtraArgs={
        "ContentType": "application/gzip",  # 显式指定内容类型，绕过SDK自动检测的阻塞逻辑
        "ContentEncoding": "gzip"
    }
)

异步aiobotocore场景的配置逻辑完全一致，同样可以用内置的upload_fileobj方法实现全内存异步上传：

import io
from aiobotocore.session import get_session
from botocore.config import Config
from boto3.s3.transfer import TransferConfig

session = get_session()
s3_config = Config(
    max_pool_connections=20,
    retries={
        "max_attempts": 3,
        "mode": "adaptive"
    }
)

async with session.create_client("s3", config=s3_config) as s3_client:
    await s3_client.upload_fileobj(
        io.BytesIO(compressed_data),
        target_bucket,
        target_object_key,
        Config=s3_transfer_config,
        ExtraArgs={
            "ContentType": "application/gzip",
            "ContentEncoding": "gzip"
        }
    )

2. 排查隐性限速点 #

• 不要对内存中的压缩流做不必要的多层缓冲包装：比如不要把BytesIO对象再包一层自定义的带阻塞读取的类，这类包装会导致TCP发送窗口长期处于低水位，直接拉低上传速度。
• 避免为每个上传任务新建独立的S3客户端：全局复用同一个带连接池的客户端，减少TCP握手开销，也能避免触发S3的单IP连接数限流。
• 不要开启SDK的CRC校验强制计算：如果业务场景对数据一致性要求不高，可以通过配置关闭传输层的全量CRC计算，减少CPU阻塞等待的时间。

3. 效果验证 #

按上述配置调整后，千兆网络环境下3GB大小的gzip压缩文件上传耗时应该在20-30秒区间，和AWS CLI的表现基本一致，也不会再出现传输中途速度骤降的问题——因为每个分片是独立的HTTP请求，单个分片的网络波动只会触发单个分片的重试，不会卡住整个上传流。

内容的提问来源于stack exchange，提问作者alt-f4