解读

面试官要的不是“背公式”，而是看候选人能否把“云厂商限速模型 + 网络实测 + 并发度推导”三步闭环。

1. 先算“理论极限”：30 秒传 10 GB → 约 2.67 Gbit/s，必须确认客户端到 S3 的带宽是否够。
2. 再算“单连接上限”：国内公有云单 TCP 流 100 Mbit/s 是常见基线，单流跑不满 2.67 Gbit/s，必须多并发。
3. 最后反推并发度：用“带宽 ÷ 单流上限”得到最小并发数，再叠加 S3 分片 5 GB 上限、重传余量、GC/CPU 抖动，给出工程值。
   如果候选人直接说“并发 32”却不提带宽验证，会被判为“拍脑袋”；只有把“先测带宽、再算并发、再留余量”讲完整，才算性能岗思维。

知识点

1. S3 Multipart Upload 规则
   • 每片最小 5 MB，最大 5 GB，最多 10 000 片。
   • 国内区域单账号默认 5 000 上传并发，可提工单扩容。
2. 国内机房实测基线
   • 同地域 ECS→S3 内网：千兆网卡 110 MByte/s 每流，万兆 1 GByte/s 每流。
   • 跨地域或公网：单流 8–12 MByte/s（100 Mbit/s 带宽+TCP 拥塞）。
3. 并发度估算公式
   N ≥ 目标吞吐 ÷ 单流吞吐 × 保险系数(1.2~1.5)
4. 性能测试套路
   • 预实验：用 1 片、5 片、10 片梯度压测，找线性区间拐点。
   • 监控：客户端 CPU、内存、fd 数；S3 返回 503 SlowDown 即触发退避。
   • 重传策略：指数退避 200 ms 起步，最大 3 次，避免放大耗时。

答案

第一步：确认带宽
在阿里云 ECS（c7 型，万兆内网）同地域访问 OSS（S3 协议）实测单流 900 Mbit/s。
目标吞吐 10 GB × 8 ÷ 30 s ≈ 2 667 Mbit/s，带宽富余，瓶颈在并发度。

第二步：选分片大小
取 128 MB/片，总片数 10 GB ÷ 128 MB ≈ 80 片，低于 10 000 上限，合理。

第三步：算并发度
单流 900 Mbit/s，理论最小并发 2 667 ÷ 900 ≈ 3；留 30 % 余量，N = 4。
预实验发现 4 并发下 CPU 占用 25 %，网络 70 %，线性良好；再涨到 6 并发无收益，故敲定 4。

第四步：工程配置

• SDK 参数：Concurrency=4，PartSize=128 MB，Timeout=60 s。
• 重试：最大 3 次，退避 200 ms。
• 监控：每片上传耗时打印日志，p99 片耗时 28 s，总耗时 29.4 s，达成 SLA。

结论：在万兆内网环境下，把分片定为 128 MB、并发度 4 即可把 10 GB 文件上传时间压到 30 秒以内；若退回到百兆公网，则需 30 并发以上并验证客户端资源。

拓展思考

1. 如果文件变成 100 GB、SLA 仍是 30 秒，如何保持并发度不线性爆炸？
   思路：把分片调到 512 MB，总片数 200，并发度 16 即可；同时启用 EC2/ECS 集群多节点并行上传不同段，再调用 S3 CompleteMultipartUpload 合并，实现“横向扩展”而非无限加大单进程并发。
2. 客户端 CPU 成为瓶颈（TLS 加密吃满）怎么办？
   思路：
   • 升配到支持 AES-NI 的机型；
   • 启用 S3 传输加速（利用 CDN 边缘节点减少 TLS 往返）；
   • 改用异步 IO 框架（如 Netty）减少线程切换。
3. 压测脚本如何复现生产场景？
   用 JMeter+自定义 Java Sampler 模拟 MultipartUpload，每线程维护一个 S3Client，通过 Stepping Thread Group 梯度加压，观察 503 SlowDown 触发阈值，把“最大可用并发”写进性能报告，为后续容量规划提供数据。