Invidious：界面、媒体路径与运维责任
Invidious 容量与成本：媒体出站、数据库状态和上游失败
建立与负载相匹配的成本记录，区分官方资源建议和自己实例的实测结果。
你将学会
- 测量流量路径，而不只是页面延迟
- 存储和后台活动需要单独预算
- 保证比较可复现，让未知值保持未知
开始前需要
- 了解 HTTP 和容器基础
- 区分应用状态与媒体流量
解释依赖和信任边界，准备可核验的试验，并在真实范围内理解源码与模型证据。
先看结论
- 媒体路由决定传输成本在哪里累积。
- 数据库、缓存和日志需要不同保留预算。
- 文档建议和字符串模型都不是生产基准。
测量流量路径，而不只是页面延迟
快速返回的搜索响应与持续很久的视频流，具有完全不同的资源特征。如果媒体经过中转，持续传输和并发观看可能远超应用 HTML 流量；如果浏览器或 companion 采用其他路径，成本发生的位置也会改变。应先弄清字节经过哪里，而不是把页面访问量乘上一个虚构的通用带宽数值。
固定安装指南描述了服务对带宽的需求，并对小型和公共部署给出不同资源建议。这些应被视为上游规划参考，不是基准测试或容量保证。编码、清晰度、观看时长、缓存、并发及供应商政策都会改变实际负载，本次没有执行真实负载测试。
存储和后台活动需要单独预算
生产示例包含 PostgreSQL 数据卷和 companion 缓存，日志也会消耗磁盘；文档组合为应用与 companion 配置了日志轮转限制。应区分用户状态增长、缓存占用和诊断保留，避免把一次缓存清理变成误删订阅或备份。
应用装配中可以看到连接池和后台任务。当上游响应缓慢或拒绝请求时，增加并发不一定提升有效吞吐，也可能只是增加同时进行的工作和失败压力。应同时测量成功率、延迟分布和资源饱和情况，而不是仅展示最快的成功请求。
保证比较可复现，让未知值保持未知
受控试验应记录应用与 companion 摘要、数据库版本、入口拓扑、代理偏好、内容选择和测量区间。区分冷启动和热请求，并说明错误，不要悄悄剔除失败样本。即使软件无需购买，供应商的出站流量价格和使用限制也属于采用决策。
下方表单有意不填写流量、存储和运行费用。十六个 URL 分流案例只是字符串正确性练习，不是吞吐、内存或价格测量。在推导月度费用之前，应公布原始观察和假设；不能把文档里的最低建议转换成某个并发观看人数的承诺。
实施步骤
- 1
绘制实际媒体与元数据路径。
- 2
记录并发观看、清晰度和测量时长。
- 3
分别测量成功、失败、传输和存储。
- 4
取得负载数据后，再套用真实供应商价格。
可复制示例
{
"measurementStatus": "not performed",
"concurrentViewers": null,
"mediaEgressBytes": null,
"databaseBytes": null,
"cacheBytes": null,
"p95PlaybackStartMs": null,
"monthlyCost": null
}常见问题
文档的硬件要求能保证某个观看人数吗？
不能。它们是规划参考，不是针对特定拓扑、视频组合或供应商实测过的容量承诺。
十六个模型测试能支持性能结论吗？
不能。它们测试字符串分类，并未运行流媒体、数据库、网络或托管负载。
资料来源
- invidious/config/config.example.yml来源核查 2026-09-08
- invidious/src/invidious.cr来源核查 2026-09-08
- documentation/docs/installation.md来源核查 2026-09-08