---
title: "性能实测"
description: "Kiln v1.1.0 预发布版本在真实上游与真实码率下的现场实测：一小时长稳、观众扇出、流量测算，以及这组数据的边界。"
---

> Documentation Index
> Fetch the complete documentation index at: https://kiln.wbxdocs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 性能实测

[Lite、Core 与 Full](/guide/variants/) 里的那组数据来自仓库内的确定性 fixture，回答的是「哪个变体更省」。这一页记录真实码率、真实上游和连续负载下的观测结果。两组数据的方法和可复现性完全不同，不要混在一起看。

下面所有数字都来自修复上游 TLS、回退参数和连接池问题后的 v1.1.0 预发布版本。该候选版本与最终发布的 `v1.1.0` 产物之间仍可能存在构建差异。

## 一小时连续双路播放

同时消费两个加密 DASH 直播源一小时：一个 4K 频道（约 15 Mbps）走同机链路，一个 1080p 频道（约 5 Mbps）经过额外网络跳点。消费端是 ffmpeg 的完整拉流与解复用，不是只请求一次清单。

| 指标 | 数值 |
| --- | --- |
| 4K 频道 | 3600 秒实际时间内消费 3551 秒媒体时间线 |
| 1080p 频道 | 3519 秒 |
| 缓冲与欠载事件 | 0 |
| CPU | 均值 3.07%，峰值 13.9%（123 个采样点） |
| 容器内存 | 均值 106 MiB，谷 27，峰 241（上限 1 GiB） |
| 上游入流量 | 约 59 分钟内 8.76 GB，记录均值 19.7 Mbps |
| 对外出流量 | 同一窗口内 8.63 GB，记录均值 19.4 Mbps |
| 服务端告警 | 0 |

CPU 百分比以单核为 100%。这次记录没有单独保存首包时刻和稳态 PTS 斜率，因此媒体时长与实际时间的差额不能拆分为起播耗时、播放列表沿偏移或运行中落后，也不能单凭这一项证明稳态始终跟上实时。

几条读得出来的结论：

- **入出流量几乎相等**（19.7 对 19.4）。这与始终拉取主视频时钟、其余轨道按请求拉取的行为一致，但本次没有关闭 rendition idle 的对照组，不能据此量化节省了多少流量。
- **内存是锯齿而不是爬坡**。谷 27、峰 241、均 106 MiB，一小时内没有单调上升，符合分片缓冲加 GC 的正常形态；峰值约占 1 GiB 上限的 24%，尚余约 783 MiB。
- **服务端计数器全零**：慢分片、重锚、失速、会话重启、握手失败都没有出现。
- 原生路径日志记录到 12 次轨道暂停和 5 次回温，直接证明 `rendition_idle_sec` 在这次运行中触发过，但本次没有量化其节省的字节数。

ffmpeg 输入链路中，4K 那一路记录到 2 条同一时间戳的 `Packet corrupt`；第二条链路记录到 13 条，其中 7 条是 `End of file`。`-c copy` 不执行解码，这些日志只能说明输入或解复用链路观察到了异常，不能仅凭数量归因。两路消费进程都没有中断。

## 观众扇出

同一个频道同时接入 1、5、10、20 个消费端，测上游拉流是否随观众数增长。

| 并发观众 | 上游入流量 | 对外出流量 | CPU | 容器内存 |
| ---: | ---: | ---: | ---: | ---: |
| 1 | 2.01 Mbps | 1.98 Mbps | 0.79% | 67 到 119 MiB |
| 5 | 4.37 Mbps | 21.2 Mbps | 1.74% | 124 到 156 MiB |
| 10 | 5.75 Mbps | 14.9 Mbps | 1.96% | 150 到 214 MiB |
| 20 | 3.84 Mbps | 72.6 Mbps | 2.27% | 143 到 165 MiB |

**本轮没有观察到上游拉流随观众数成比例增长。** 入流量在 1 到 20 个观众之间始终落在 2 到 6 Mbps 这一档，20 个观众时（3.84）低于 10 个观众时（5.75），而同期对外出流量到了 72.6 Mbps。

服务端计数器给出了更直接的证据：整个过程中 `kiln_sessions` 始终为 1，上游分片拉取速率在 10 个观众时为每 10 秒 4.3 个，20 个观众时为 3.9 个，而在没有观众、频道尚未空闲超时的间隙里是每 10 秒 3 个。它们处于同一量级，说明这些观众共享同一份上游会话。每档只有一个 60 秒窗口，因此这组数据不建立观众数与上游字节数的统计独立关系。

这次样本里，CPU 从 1 个观众时的 0.79% 增至 20 个观众时的 2.27%，慢于观众数增长；内存没有呈现单调关系。要把这种关系当作容量结论，需要延长窗口并重复多轮。

这些消费端都选了 master 里的第一个渲染层（576p50，约 2 Mbps 含音轨），所以这组数字证明的是**同一渲染层的扇出**。观众选择非主渲染层时，上游会保留一份主视频轨作为时钟，并为每个被请求的非主轨各拉一份。

> **出流量这一列只能读量级**
>
> 对外出流量波动很大，10 个观众时反而低于 5 个观众时。消费端不限速，各自的缓冲位置不同，取用时刻会聚成簇，而 60 秒的计数窗口只覆盖约 7 个分片周期，样本太小压不住这种成簇。这一列只能用来看量级，也就是出流量可以是上游入流量的十几倍，不能当作每观众的稳态速率，更不能当作容量上限。要得到可用的容量结论，需要把窗口拉长到几分钟并重复多轮。

## 流量测算

选择主视频轨时，可按其名义码率估算单人观看的上游消耗量级；选择非主轨时还会保留主视频时钟：

| 渲染层 | 每小时 | 每天看 2 小时的月消耗 |
| --- | ---: | ---: |
| 约 2 Mbps（576p 加音轨） | 0.9 GB | 约 54 GB |
| 约 5 Mbps（1080p 加音轨） | 2.3 GB | 约 135 GB |
| 约 15 Mbps（4K 加音轨） | 6.8 GB | 约 405 GB |

双路测试的流量计数窗口约为 59 分钟，并非完整一小时，不能把 8.76 GB 直接和 9.0 GB 的小时估算比较。按记录均值 19.7 Mbps 折算约为 8.9 GB/小时；由于没有保留精确窗口秒数与原始字节数，这里不进一步归因差值。表格只适合作为流量配额的初步估算，部署时应以自己的长窗口实测并预留余量。同一频道、同一渲染层的多个观众共享一份上游会话。

## 直播延迟

这次采样测的是播放列表沿相对上游时间戳的滞后，不是播放器画面的端到端延迟。端到端结果还会受输出引擎、播放列表窗口和播放器缓冲影响；原生引擎与 ffmpeg 兼容路径的输出结构不同，不能共用一组 `TARGETDURATION` 或 LL-HLS part 参数来推导。

> **这里不给实测延迟数字**
>
> 我们测过播放列表沿落后实时多少秒，但多轮结果无法复现：同一个频道在不同轮次里 7 秒到 55 秒都出现过，两个频道之间的高低关系也会整个反转。这个量既取决于采样落在分片周期的哪个相位，也取决于上游自己写在 `EXT-X-PROGRAM-DATE-TIME` 里的时间戳是否准确，而后者不在 Kiln 的控制范围内。在拿到可复现的测法之前这里不给数字，请在自己的链路上实测。

> **这组数据不能支持什么**
>
> 这是一台机器、一条源站链路、一次部署的现场测量，不是可复现的受控基准。本文不提供精确源站链路，因此这些绝对值不应泛化到其它环境。现存记录没有逐频道保存一小时测试的 `engine` 与 `pack_mode`，所以不能拆分原生路径和 ffmpeg 兼容路径各自的资源开销。它也没有覆盖两个以上频道的并发拉流、超过一小时的长稳、冷启动首帧时间的分布，以及非 arm64 架构。扇出测试的消费端全部在同一台宿主机的回环上，不含真实网络的 TCP 行为，观众分散在公网时出口侧的表现会不同。CPU 百分比与具体 CPU 绑定，换架构不能直接迁移。

### 测试环境与方法

测量运行在限制 1 GiB 内存的 arm64 容器中，被测构建为 v1.1.0 预发布版本。

源站为两个加密 DASH 直播流，经 HTTP 转发代理访问，上游分片时长 8 秒。消费端统一使用 ffmpeg 的 `-c copy -f null -`，完整拉流并解复用但不转码，测的是真实分片下载与封装链路。4K 流走同机链路并作为主判据；1080p 流经过额外网络跳点，只作参考，因为该链路会引入无关抖动。

CPU 与内存取自容器的 cgroup v2 计数器（`cpu.stat` 的 `usage_usec` 与 `memory.current`），流量取自容器 `eth0` 的 `/proc/net/dev` 精确字节计数。只保留三位有效数字的汇总网络计数不足以在 GB 量级做短窗口差分。

扇出测量在每档开始后先等 75 秒，让消费端追帧的突发下载过去、进入稳态，再开 60 秒的计数窗口，并在窗口两端确认消费端仍然存活。缓冲判据同时取两侧：消费端 ffmpeg 日志里的欠载与失速，以及 Kiln 服务端的慢分片、重锚、失速、会话重启和握手失败计数。

### 在自己的部署上复现

上面的链路无法直接复现。仓库里的 `scripts/live-performance.sh` 可以对自己的频道做相近的单频道短测，覆盖冷启动、首个清单响应时间、吞吐实时比、峰值 RSS 与峰值 CPU；它直接运行宿主机进程并通过 `ps` 采样，不会复现本文的长稳、扇出或容器 cgroup 测量：

```bash
KILN_PERF_CONFIG=/path/to/your/kiln.toml \
KILN_PERF_CHANNELS=my-channel \
KILN_PERF_CAPTURE_SECONDS=60 \
  sh scripts/live-performance.sh
```

长稳与扇出没有现成脚本，方法本身不复杂：用 ffmpeg 以 `-c copy -f null -` 消费自己的频道，同时按固定间隔采样容器的 cgroup 计数器。要点是先等稳态再开计数窗口，并在窗口两端确认消费端还活着，否则测到的是追帧突发而不是稳态。

Source: https://kiln.wbxdocs.com/guide/performance/index.mdx