# S3 API 基准测试

## 概述

摘要

* 三种基准测试工具，各有一页文档：[**COSBench**](/ee-ai-cn/benchmark/s3-api/cosbench.md)（复杂混合工作负载）、[**Warp**](/ee-ai-cn/benchmark/s3-api/warp.md)（快速的 bucket 级读取）、[**httpbench**](/ee-ai-cn/benchmark/s3-api/httpbench.md)（约 50 行的 Go 小工具，专门用于 redirect 模式集群的单 worker 测量）。
* 三组不同硬件的参考性能基线（AWS 4 节点 COSBench、OCI 6 节点 Warp、AWS 6 节点 httpbench）。
* **对象大小很关键。** 对于 1 GiB 以上的对象（典型的 AI 模型分片），Alluxio 的 HTTP 307 重定向在 keep-alive 热连接上的开销几乎为 0%。对于小对象（<100 KiB），握手开销占主导，吞吐量最多可损失一半——此时两种模式差距明显。
* 关键的潜在性能瓶颈：网络带宽、TCP 连接复用、HTTP 重定向开销（仅小对象）、内核调优。

有关 Alluxio S3 API 的工作原理（请求流程、一致性哈希、重定向），请参阅 [架构概述](/ee-ai-cn/data-access/s3-api.md#gong-zuo-yuan-li)。

## 基准测试工具选型

|                   | [COSBench](/ee-ai-cn/benchmark/s3-api/cosbench.md)        | [Warp](/ee-ai-cn/benchmark/s3-api/warp.md) | [httpbench](/ee-ai-cn/benchmark/s3-api/httpbench.md) |
| ----------------- | --------------------------------------------------------- | ------------------------------------------ | ---------------------------------------------------- |
| **最适合**           | 复杂的多阶段工作负载                                                | 快速的 bucket 级单操作测试                          | redirect 模式集群下的单 worker 吞吐测量                         |
| **部署**            | Controller + Driver 节点                                    | 单一可执行文件                                    | 约 50 行 Go，在客户端上编译                                    |
| **工作负载定义**        | XML 配置文件                                                  | CLI 参数                                     | 命令行 URL 列表                                           |
| **是否跟随 HTTP 307** | 跟随（via SDK）——需要 `alluxio.worker.s3.redirect.enabled=true` | **不跟随** —— 与 redirect 模式不兼容                | 跟随（Go 默认）——两种模式都能用                                   |
| **多客户端协调**        | 内置 Driver 模型                                              | `--syncstart`                              | ssh + 时间戳协调                                          |
| **结果展示**          | Web 仪表盘                                                   | 终端输出                                       | 终端输出                                                 |

**选型准则**：

* **集群启用 redirect，需要单 worker 隔离**（比如单独 CPU profiling 某个 worker，或测量单张 NIC）：用 [**httpbench**](/ee-ai-cn/benchmark/s3-api/httpbench.md)。
* **redirect 关闭，想要快速的 bucket 级数字**：用 [**Warp**](/ee-ai-cn/benchmark/s3-api/warp.md)。
* **读写混合、多 Driver、长时间运行或复杂分阶段工作负载**：用 [**COSBench**](/ee-ai-cn/benchmark/s3-api/cosbench.md)。

## 参考性能基线

下方所有吞吐量数据均假设数据**完全缓存在 Alluxio 中**。如果数据从底层 UFS 提供服务，吞吐量将显著降低。测试前请使用 `bin/alluxio fs check-cached /path` 进行验证。

### 4 节点 COSBench（AWS）

以下结果是使用一个 4 驱动程序的 COSBench 集群测试一个 4 工作节点的 Alluxio 集群得出的。

| 组件                  | 配置                                  |
| ------------------- | ----------------------------------- |
| COSBench Controller | 1 × `c5n.metal`                     |
| COSBench Drivers    | 4 × `c5n.metal`                     |
| Alluxio Coordinator | 1 个节点                               |
| Alluxio Workers     | 4 × `i3en.metal`（每个节点 8 个 NVMe SSD） |
| 负载均衡器               | 跨 4 个工作节点的 AWS ELB                  |

**大文件读取吞吐量（1 GB 文件）** — 受带宽限制，随并发数增加而扩展直到网络饱和：

| 每个驱动程序的并发数 | 总吞吐量       |
| ---------- | ---------- |
| 1 个线程      | 2.35 GB/s  |
| 16 个线程     | 20.44 GB/s |
| 128 个线程    | 36.94 GB/s |

**小文件读取 IOPS（100 KB 文件）** — 受 IOPS 限制，随并发数增加而扩展直到 CPU 饱和：

| 每个驱动程序的并发数 | 总吞吐量       | 总操作数/秒      |
| ---------- | ---------- | ----------- |
| 1 个线程      | 50.26 MB/s | 502 op/s    |
| 16 个线程     | 1.10 GB/s  | 11,302 op/s |
| 128 个线程    | 4.69 GB/s  | 46,757 op/s |

### 6 节点 Warp（OCI）

在 OCI `BM.DenseIO.E5.128` 节点（100 Gbps 网络，12 个 NVMe 组成 RAID 0）上的 Warp GET 测试中，Alluxio 在单节点上实现了 11.2 GiB/s 的吞吐量（平均延迟 0.3 ms，P99 延迟 0.4 ms），在 6 节点上实现了 33.3 GiB/s（平均延迟 0.6 ms，P99 延迟 0.9 ms）。请注意，Warp 不跟随指向非 AWS endpoint 的 HTTP 307 重定向，因此以上数据对应[模式 B：负载均衡 + 代理模式](https://documentation.alluxio.io/ee-ai-cn/benchmark/pages/byWXUfjCc1iGJqCfxSkb#模式-b负载均衡-代理模式)（负载均衡器 + 代理模式）。完整结果请参阅 [Alluxio on OCI](https://blogs.oracle.com/cloud-infrastructure/post/alluxio-on-oci-submillisecond-latency-for-ai)。

### 6 节点 httpbench（AWS）

在 6 × `c5n.18xlarge` worker（72 vCPU、192 GiB 内存、100 Gbps 网卡、80 GiB tmpfs page store）+ 6 × `c5n.18xlarge` 客户端上运行，服务 82 个 safetensor 文件（共约 137 GB，每个 1–3 GiB），数据已在 Alluxio 中完全缓存。工具：[httpbench](/ee-ai-cn/benchmark/s3-api/httpbench.md)。

**单 worker，单客户端（1:1），1–3 GiB 对象**：

| 并发     | 吞吐量                        | 相对 iperf3 上限 |
| ------ | -------------------------- | ------------ |
| 1      | 0.62 GB/s (5.0 Gbps)       | AWS ENA 单流上限 |
| 16     | 8.66 GB/s (69.3 Gbps)      | 87%          |
| **32** | **11.35 GB/s (90.8 Gbps)** | **95%**      |
| 64     | 11.15 GB/s (89.2 Gbps)     | 已饱和          |
| 128    | 10.46 GB/s (83.7 Gbps)     | 连接数过多带来的开销   |

本地读取时，单个 worker 的 S3 API 能为单个客户端提供接近 TCP 线速（iperf3）95% 的吞吐。

**6 客户端 × 6 worker 成对聚合（每客户端 C=32，30s）**：

| 指标                                     | 数值                        |
| -------------------------------------- | ------------------------- |
| 每对平均                                   | 11.43 GB/s (91.4 Gbps)    |
| **聚合吞吐**                               | **68.55 GB/s (548 Gbps)** |
| Worker CPU 平均（72 vCPU，`mpstat -P ALL`） | 4.1% ≈ **3 核平均**          |
| Worker CPU 峰值                          | 7.2–8.2% ≈ **5–6 核峰值**    |

吞吐从每对 11.4 GB/s 到 6 对 68.5 GB/s 近线性扩展。聚合期间 worker CPU 几乎空闲——对于大对象读取，Alluxio 是 NIC-bound 而非 CPU-bound。

### 网络上限（iperf3 基线）

同一测试环境下，客户端与 worker 之间的裸 TCP 吞吐（供对照参考）：

| TCP 流数 | 吞吐量                                           |
| ------ | --------------------------------------------- |
| 1      | 4.97 Gbps (0.62 GB/s) — AWS ENA 单流上限          |
| 8      | 37.9 Gbps                                     |
| 32     | **95.6 Gbps (11.95 GB/s)** — 接近 100 Gbps 网卡线速 |

在该硬件下，任何单客户端的 S3 API 吞吐超过约 95 Gbps 都不可能，无论集群规模——NIC 就是天花板。解读 S3 API 数据前，先用 `iperf3 -c <worker> -P 32` 建立此上限。

## 307 重定向开销：大对象 vs 小对象

[S3 API 文档](https://documentation.alluxio.io/ee-ai-cn/benchmark/pages/byWXUfjCc1iGJqCfxSkb#部署模式)里"模式 B（代理模式）≈ 模式 A（redirect）吞吐的 50%"这条经验，**仅适用于小对象工作负载**——那里每个请求都被 307 握手开销主导。对于大对象顺序读（1 GiB+ 分片，典型 AI 模型加载场景），握手只发生一次然后被摊薄到接近于零——在我们的测试里，模式 A 和模式 B 的吞吐相差约 2% 以内（1–3 GiB 对象，C=64 下模式 B 11.28 GB/s vs 模式 A 11.02 GB/s；C=128 下模式 B 10.80 GB/s vs 模式 A 10.89 GB/s）。

经验法则：如果 `平均对象字节数 / 网卡每秒字节数` 远大于 307 重定向 RTT（同可用区通常约 1 ms），重定向开销就可以忽略不计。100 Gbps 网卡下，这意味着：100 MB 以上对象重定向开销基本为 0，1 GB+ 对象开销可忽略不计（<2%）；对于小于 1 MB 的对象，握手占主导，模式 B 吞吐会回落到模式 A 的约 50%。

## 性能调优与故障排除

有关建议的 Alluxio 配置参数和 Linux 内核调优，请参阅 [S3 API — 性能](https://documentation.alluxio.io/ee-ai-cn/benchmark/pages/byWXUfjCc1iGJqCfxSkb#性能)。各个工具特有的故障排查请见每个工具自己的页面。

跨工具通用症状：

* **小对象吞吐比预期低约 50%** — 对于 <100 KiB 的小对象工作负载，重定向很可能已被禁用（`alluxio.worker.s3.redirect.enabled=false`，默认值），因此跨工作节点的读取会通过中间节点代理，而不是由数据所在节点直接提供服务。若要获得完整吞吐量，请使用 Pattern A：将 `alluxio.worker.s3.redirect.enabled=true` 与支持重定向的客户端配合使用。参见[部署模式](https://documentation.alluxio.io/ee-ai-cn/benchmark/pages/byWXUfjCc1iGJqCfxSkb#部署模式)。对于大对象（1 GiB+），Pattern A 与 Pattern B 吞吐几乎没有差距——重定向开销可以忽略，见 [307 重定向开销：大对象 vs 小对象](#id-307-zhong-ding-xiang-kai-xiao-da-dui-xiang-vs-xiao-dui-xiang)。
* **吞吐量远低于基线** — 最可能的原因是数据未完全缓存。在测试前使用 `bin/alluxio fs check-cached` 验证文件已缓存在 Alluxio 中。
* **高并发下吞吐量仍然很低** — 网络瓶颈或负载均衡器分配不均。验证 100 Gbps 连接、同可用区部署，以及负载均衡器是否将请求均匀分配到所有 Alluxio 工作节点。测试前先用 `iperf3` 建立 NIC 上限——参见[网络上限（iperf3 基线）](#wang-luo-shang-xian-iperf3-ji-xian)。
* **增加并发数后无法扩展** — CPU 或连接池瓶颈。检查工作节点 CPU 使用率，确保已启用 `alluxio.worker.s3.connection.keep.alive.enabled`。
* **尾部延迟高** — TCP 端口耗尽。应用[内核调优](https://documentation.alluxio.io/ee-ai-cn/benchmark/pages/byWXUfjCc1iGJqCfxSkb#linux-内核参数)参数（`tcp_tw_reuse`、`tcp_fin_timeout`）。
* **吞吐量在较低水平停滞** — 健康检查开销。在基准测试时禁用 `alluxio.worker.s3.redirect.health.check.enabled`。
* **多次运行结果不一致或波动较大** — 数据未完全缓存，或存在环境干扰（跨可用区流量、共享网络）。预加载数据后在专用的同可用区环境中重新运行。

## 另请参阅

* [COSBench 基准测试](/ee-ai-cn/benchmark/s3-api/cosbench.md) — 复杂的多阶段工作负载
* [Warp 基准测试](/ee-ai-cn/benchmark/s3-api/warp.md) — 单二进制快速测试，仅限 redirect 关闭的集群
* [httpbench 基准测试](/ee-ai-cn/benchmark/s3-api/httpbench.md) — 单 worker、redirect 感知
* [S3 API 设置与配置](/ee-ai-cn/data-access/s3-api.md) — 部署模式、端点设置、负载均衡器配置和客户端示例
* [S3 UFS 集成](/ee-ai-cn/ufs/s3.md) — 分片上传调优、高并发设置和 S3 区域配置


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.alluxio.io/ee-ai-cn/benchmark/s3-api.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.