跳转到内容
DepsiloDocs
GitHub

验证缓存与下载收益

用同一份 npm 制品的重复下载、访问日志和直连对照，验证 Depsilo v0.11.0 的缓存行为并记录实际测量结果。

先确认一份依赖是否经过 Depsilo、第二次是否命中缓存，再测量它在你的网络里带来的变化。本页提供可执行的方法，不预设提速倍数。

需要已完成首次设置的 v0.11.0 实例，以及 Linux 或 macOS 上的 curl、Python 3 和 POSIX shell。默认 npm 上游应可用；启用了包规则时，测试包也需要满足这些规则。

取得实例返回的制品地址

链接到“取得实例返回的制品地址”小节

以下步骤固定使用 [email protected]，只下载文件，不执行包代码或修改包管理器配置。在同一个终端中逐段运行，确认每一步成功后再继续。

终端窗口
DEPSILO_URL='http://127.0.0.1:23333'
depsilo_check_dir=$(mktemp -d "${TMPDIR:-/tmp}/depsilo-cache-check.XXXXXX")


curl -fsS --max-time 30 "$DEPSILO_URL/npm/is-number" \
  -o "$depsilo_check_dir/metadata.json"


depsilo_tarball=$(python3 -c \
  'import json, sys; print(json.load(open(sys.argv[1]))["versions"]["7.0.0"]["dist"]["tarball"])' \
  "$depsilo_check_dir/metadata.json")

把 DEPSILO_URL 换成客户端可达的实例地址，末尾不加 /；从其他机器测试时，127.0.0.1 不是服务器地址。使用 HTTPS 反向代理时，先按部署指南配置转发协议。

dist.tarball 是 Depsilo 根据上游元数据生成的带来源绑定的地址。保持该地址原样：v0.11.0 不接受手工拼接的 /npm/包名/-/文件名.tgz 下载路径。上面的元数据请求与后面的制品请求是不同的日志记录。

下载两次，再做直连对照

链接到“下载两次，再做直连对照”小节
终端窗口
curl -fsSL --max-time 120 "$depsilo_tarball" \
  -o "$depsilo_check_dir/first.tgz" \
  -w 'depsilo_first status=%{http_code} seconds=%{time_total} bytes=%{size_download}\n'


curl -fsSL --max-time 120 "$depsilo_tarball" \
  -o "$depsilo_check_dir/repeat.tgz" \
  -w 'depsilo_repeat status=%{http_code} seconds=%{time_total} bytes=%{size_download}\n'


curl -fsSL --max-time 120 \
  'https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz' \
  -o "$depsilo_check_dir/direct.tgz" \
  -w 'npm_direct status=%{http_code} seconds=%{time_total} bytes=%{size_download}\n'


cmp "$depsilo_check_dir/first.tgz" "$depsilo_check_dir/repeat.tgz" && \
  cmp "$depsilo_check_dir/first.tgz" "$depsilo_check_dir/direct.tgz" && \
  printf 'OK: all three downloads contain the same bytes.\n'

普通 curl 不维护 npm 那样的包缓存，因此每条命令都会发起下载请求。文件保存在独立的临时目录中；cmp 成功时没有输出，最后一行确认三次下载内容相同。若某条请求失败或文件不同，先查清原因，不将它记作一次成功的性能样本。

用访问日志确认命中

链接到“用访问日志确认命中”小节

打开 Admin → Access logs（/admin/logs），查找刚才两次 npm 制品请求，核对包、版本、时间、状态与命中结果。不要用更早的元数据请求代替制品记录。

观察 能确认什么
第一次制品请求成功，日志显示未命中 这一轮确实发生了冷缓存下载。
第二次同一制品请求成功，日志显示命中 Depsilo 复用了已缓存的内容。
两次都显示命中 这个制品此前已缓存；本轮没有取得冷缓存样本。
请求未出现在日志中 先检查实例地址、返回的制品 URL 和反向代理；下载成功不能单独证明经过 Depsilo。
451 或其他失败状态 检查对应策略或上游问题；失败响应不参与成功下载的耗时比较。

需要冷缓存样本时，使用单独的测试实例和新状态卷，或选择确认尚未缓存的固定版本。保留日常实例的现有缓存。

怎样解读测量结果

链接到“怎样解读测量结果”小节
  • seconds 是客户端观察到的整个 HTTP 请求耗时，包含连接、传输和等待，不是整个项目的构建时间。
  • bytes 是交付给客户端的字节数。缓存命中仍要交付同一文件，所以三次通常相同。节省的公网流量发生在 Depsilo 与上游之间，需要结合服务端回源流量观察。
  • 直连对照使用 npm 官方源。如果 Depsilo 配置了另一个镜像，这同时比较了不同网络路径；记录实际使用的上游，不把差异全部归因于缓存。
  • is-number 很小，适合检查连接与命中。评估实际收益时，再用你的代表性依赖集合，保持项目版本、lockfile、客户端缓存状态和网络条件一致。
  • 分别重复热缓存与直连测量数轮，记录中位数和范围。若同时有其他用户请求服务，流量统计可能包含他们的下载。

可以用下面的表格保存实际结果，公开分享时附上命令和测试条件：

项目 需要记录的内容
环境 Depsilo 版本、客户端与服务位置、存储方式、网络和上游地址
冷缓存 首次请求耗时、文件大小、访问日志中的未命中结果；未测到就注明
热缓存 每轮耗时、文件大小、对应命中记录
直连 每轮耗时、官方源或其他明确指定的源
结论 本次条件下观察到的差异，以及尚未覆盖的项目或网络条件

确认缓存行为后，继续连接项目的包管理器；结果不符合预期时，参考故障排查。