OkFile 文件上传性能实测：10MB、100MB、500MB 三组样本对比
本次测试的核心目标非常明确：评估 OkFile 在不同文件体积下的实际上传耗时与吞吐量表现。我们直接给出可复用的基准数据，便于后续脚本集成、自动化部署以及大文件处理场景的参考。
测试覆盖三个文件体积档位：10MB、100MB 和 500MB，全面涵盖从小文件到中大型文件的典型使用场景。
测试环境
- 操作系统：Windows
- Python 版本：3.13.12
- 测试方法：通过 OkFile CLI 及内部上传接口执行真实文件上传
- 测试对象：单文件上传链路
测试结果
| 文件 | 大小 | 耗时 | 吞吐 |
|---|---|---|---|
| okfile_perf_10mb.bin | 10.0 MiB | 7.80 s | 1.282 MiB/s |
| okfile_perf_100mb.bin | 100.0 MiB | 31.751 s | 3.150 MiB/s |
| okfile_perf_500mb.bin | 500.0 MiB | 157.797 s | 3.169 MiB/s |
结果解读
综合几组数据，可以清晰地看到以下几个关键结论。
1. 小文件场景：固定开销占据主导
10MB 文件耗时 7.80 秒，对应平均吞吐仅 1.282 MiB/s，明显低于 100MB 和 500MB 样本。原因在于：小文件上传时，连接建立、握手协商、链路初始化等固定成本在总耗时中占比过高。这是大多数上传系统面临的共性问题——文件越小，传输效率越低，但并非链路本身存在瓶颈。
2. 100MB 与 500MB：进入稳定传输区间
当文件体积达到 100MB 和 500MB 时，吞吐表现趋于一致——100MB 为 3.150 MiB/s，500MB 为 3.169 MiB/s，两者几乎持平。这表明大文件上传阶段，链路已进入稳定传输状态，带宽利用率接近饱和，不再受固定开销的显著影响。
3. 大文件持续传输：未见异常退化
500MB 文件总耗时约 157.8 秒，但吞吐与 100MB 基本持平。这是一个积极信号：上传链路在后段没有出现明显的性能衰减，例如丢包重传率上升、缓冲区溢出等问题。对于需要长时间持续上传的场景，本次测试验证了链路的稳定性。
对接入方的建议
- 小文件传输时，不要仅关注单次耗时，固定开销会明显拉低平均吞吐，评估时应将这部分成本纳入考量。
- 对于 100MB 以上的文件，可按约 3.1 MiB/s 的吞吐量估算上传时间，偏差较小。
- 在批量上传任务中，强烈建议将结果（包括成功、失败、耗时）记录到 JSON 或日志文件，便于审计、重放或补传操作。
- 大文件场景下，建议保留进度落盘和失败重试机制——一次上传可能耗时数十分钟，中断重来的成本过高。
测试方法说明
10MB 样本通过 CLI 执行上传，并从日志中提取完成时间。100MB 和 500MB 样本则通过 Python 脚本直接调用上传链路，执行完成后将结果输出为 JSON 文件。需要强调：所有数据均来自真实上传过程，而非本地模拟或理论推算。测试链路未做任何特殊调优，保持常规配置。
结论
在当前环境下，OkFile 能够稳定完成 10MB、100MB 和 500MB 三个档位的真实文件上传。100MB 与 500MB 的吞吐已接近稳定平台，大文件场景具备可预期的持续传输能力。该数据可作为后续集成开发的基础参考。
