Nx CLI 基准测试实战用 1110 项目合成工作区度量任务流水线性能【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nxNx 官方仓库在benchmarks/目录下内置了一套自研基准测试Benchmark工作区它用 1110 个轻量项目模拟超大规模 Monorepo配合 hyperfine 度量 Nx CLI 的启动、项目图构建、任务调度与缓存命中等多个维度的耗时并通过goals.json目标值与本地baseline.json基线形成可量化的性能回归防线。读完本文你将掌握这套基准测试的设计思路、五个bench:*目标的含义、目标/基线对比机制的实现细节以及如何在 CI 中用它守护 Nx 的性能底线。一、基准测试工作区设计三层扇出结构整套基准测试以一个**合成工作区Synthetic Workspace**为载体其结构与真实大型 Monorepo 对齐1110 个项目以三层扇出3-level fan-out排布10 groups × 10 subs × 10 leaves每个项目都定义build、copy、cat三个 target所有 target 都操作同一个共享文件 lorem.md标准 Lorem Ipsum 文本不做真实编译只保留足够的文件 I/O 来考验 Nx 的任务流水线task pipeline。从仓库中的实际项目文件可以清晰地看到这棵依赖树见 benchmarks/packages/group-01、benchmarks/packages/group-01/sub-01组节点 group-01/project.json 只声明name与三个空 target子节点 sub-01/project.json 通过implicitDependencies: [group-01]隐含依赖组节点叶子节点 leaf-01/project.json 同样通过implicitDependencies: [group-01-sub-01]形成三层依赖链。叶子节点的真实名称如group-01-sub-01-leaf-011110 个项目由此生成为run-many -t ...提供了足够的并发规模压力。二、Workspace Targets三个精心设计的测量探针README 用一张表概括了三个 target 的行为详见 benchmarks/README.mdTarget命令缓存输出依赖buildcp lorem.md → dist/output.md是是^buildcopycp lorem.md → copy-out/output.md是是无catcat lorem.md是否无它们的底层实现位于 benchmarks/nx.json 的targetDefaults中关键配置如下{ targetDefaults: { build: { command: mkdir -p {projectRoot}/dist cp lorem.md {projectRoot}/dist/output.md, dependsOn: [^build], cache: true, inputs: [ {projectRoot}/**/*, {workspaceRoot}/lorem.md, { dependentTasksOutputFiles: **/* } ], outputs: [{projectRoot}/dist] }, cat: { command: cat lorem.md, cache: true, inputs: [{projectRoot}/**/*, {workspaceRoot}/lorem.md] }, copy: { command: mkdir -p {projectRoot}/copy-out cp lorem.md {projectRoot}/copy-out/output.md, cache: true, inputs: [{projectRoot}/**/*, {workspaceRoot}/lorem.md], outputs: [{projectRoot}/copy-out] } }, analytics: false, parallel: 5 }从中可以读出三层测量意图build 带拓扑依赖dependsOn: [^build]要求子项目先于父项目构建且dependentTasksOutputFiles: **/*把依赖任务的产物纳入输入哈希专门用来考验 Nx 的拓扑排序 跨任务缓存联动能力README 注明该场景当前在基准列表中处于 disabled 状态即build-warmcopy 带输出追踪有outputs声明可完整走一遍缓存命中 → 恢复输出产物的路径cat 无输出产物cat只有 stdout无输出目录用来测量纯调度 哈希计算的最小开销。此外parallel: 5控制了run-many的并行度整个工作区关闭了 analytics避免遥测干扰测量数据。三、环境准备与快速开始前置依赖基准测试依赖 hyperfine 作为计时工具安装方式cargo install hyperfine同时需要 pnpm仓库根目录使用 pnpm-workspace.yaml 与 pnpm-lock.yaml 管理依赖因为所有命令都通过 pnpm 触发。一键运行全部基准# 运行所有基准并与 goals baseline 对比 pnpm nx run benchmarks单独运行某个基准pnpm nx bench:version benchmarks pnpm nx bench:show-projects benchmarks pnpm nx bench:cat-warm benchmarks pnpm nx bench:copy-warm benchmarks值得注意每个bench:*target 都dependsOn: ^build见 benchmarks/package.json 的nx.targets配置这意味着执行基准前会先编译 Nx 各包——因为基准命令实际调用的是node ../packages/nx/dist/bin/nx.js必须保证产物存在。所有bench:*还都设置了parallelism: false确保基准按序串行执行互不抢占资源。四、五个基准测试详解基准实际执行的命令度量维度versionnx --versionCLI 启动与模块加载耗时show-projectsnx show projects通过 daemon 构建项目图cat-warmrun-many -t cat×1110无输出产物场景下的任务调度 哈希copy-warmrun-many -t copy×1110带输出追踪的缓存任务执行build-warmrun-many -t build×1110带拓扑依赖的缓存任务当前禁用它们在 benchmarks/package.json 的scripts中都有完整定义例如bench:version: NX_NO_CLOUDtrue hyperfine --show-output --setup node ../packages/nx/dist/bin/nx.js reset --warmup 1 --min-runs 10 --export-json results-version.json node ../packages/nx/dist/bin/nx.js --version, bench:show-projects: NX_NO_CLOUDtrue hyperfine --show-output --setup node ../packages/nx/dist/bin/nx.js reset --warmup 1 --min-runs 5 --export-json results-show-projects.json node ../packages/nx/dist/bin/nx.js show projects --tuifalse所有基准遵循相同的测量纪律README 中明确说明统一设置NX_NO_CLOUDtrue彻底隔离 Nx Cloud 网络层只测本地性能每次迭代前通过--setup执行nx reset清空 daemon 与缓存状态保证每次测量都从冷启动开始每个基准至少采集5 次version为10 次取统计值version之外都带 1 次--warmup预热结果以 hyperfine 的--export-json形式写入results-name.json文件。从命令细节还能看出不同基准的差异show-projects使用--tuifalse关闭交互界面而build-warm使用--tuitrue --tui-auto-exit主动开启 TUI 并自动退出用以覆盖 TUI 渲染路径下的真实耗时。五、目标与基线性能回归的双保险性能数据由两个文件共同承载文件是否提交作用goals.json提交committed团队约定的目标耗时CI 中基准超时即失败baseline.jsongitignore本地生成本地机器的个人对比基线goals.json的当前目标值单位为秒max字段{ version: { max: 0.05 }, show-projects: { max: 0.1 }, cat-warm: { max: 0.3 }, copy-warm: { max: 0.5 }, build-warm: { max: 0.75 } }即CLI 启动 50ms 内、项目图构建 100ms 内、1110 个无输出任务 300ms 内、带输出追踪的缓存任务 500ms 内、带拓扑依赖的缓存任务 750ms 内。这些数字直接构成 CI 的硬性回归门槛。设置本地基线# 首次运行会自动创建 baseline.json pnpm nx run benchmarks # 显式用本次结果覆盖基线 pnpm nx run benchmarks -- --set-baseline--set-baseline参数由 run-benchmarks.ts 解析process.argv.includes(--set-baseline)它会将本次五个基准的mean均值写入baseline.json。基线文件是本地专属、不入库的因此换机器后首次运行会自动重新生成这保证了团队内每台开发机都有与自己硬件匹配的参照系。六、执行流程与对比脚本原理README 把整个流程归纳为三步每个bench:*脚本调用 hyperfine生成对应的results-name.jsonruntarget 通过dependsOn依赖全部五个bench:*且它们都parallelism: false按序执行全部完成后run-benchmarks.ts读取结果文件并打印对比表格。runtarget 的依赖顺序在 benchmarks/package.json 中为run: { dependsOn: [ bench:version, bench:show-projects, bench:cat-warm, bench:copy-warm, bench:build-warm ] }对比脚本实现细节run-benchmarks.ts 是整套机制的大脑值得关注的技术点结果读取loadResult()读取results-name.json直接取 hyperfine JSON 中的raw.results[0]包含mean、stddev、min、max时间格式化formatMs()把秒转毫秒≥1s 显示为x.xxs否则显示为xxxms增量计算formatDelta()输出相对百分比如12%彩色对比表表头为Benchmark | Goal | Baseline | Current每个基准行以(goalDelta | baselineDelta)形式展示双重增量——相对目标mean goal.max显示绿色超标显示红色相对基线比基线快 10% 以上ratio -0.1显示绿色慢 10% 以上ratio 0.1显示红色其余为灰色避免微小波动引起噪音健壮性某个results-name.json缺失或损坏时loadResult返回null并跳过该行若一个结果都没有脚本以错误码退出并提示先运行单个基准。对比表同时回答两个问题本次是否突破团队目标对照 goals和相比我本机上次表现如何对照 baseline。七、CI 集成目标即门槛README 明确指出基准测试运行在 CI 的affected target 流水线中nx affected --targets...benchgoals.json中的目标值充当回归闸门regression gate任何一次改动导致对应基准的平均耗时超过goals.json中的max值时CI 即失败。这也是为什么goals.json必须提交入库——它是团队集体认可的性能契约。另外run-benchmarks.ts 对 CI 环境做了专门适配当process.env.CI存在时不会打印To update baseline之类的交互提示保证 CI 输出干净、可解析而在本地运行时脚本会在表格末尾温和提示pnpm bench -- --set-baseline命令注意该提示是脚本内置输出实际更新基线仍应使用 README 中的pnpm nx run benchmarks -- --set-baseline。八、扩展阅读如果想进一步深入这套基准设施建议按以下顺序阅读仓库中的关键文件benchmarks/README.md — 基准测试的总纲与使用入口benchmarks/package.json — 五个基准的 hyperfine 命令与 Nx target 编排benchmarks/nx.json —build/copy/cat三个 target 的targetDefaults与输入/输出/缓存声明benchmarks/run-benchmarks.ts — goals/baseline 对比与彩色表格的完整实现benchmarks/goals.json — 当前性能目标值benchmarks/lorem.md — 所有任务共享的操作文件benchmarks/packages/group-01 与 benchmarks/packages/group-01/sub-01/leaf-01/project.json — 三层扇出项目结构及隐含依赖的样板packages/nx — 被基准的 Nx 核心包源码基准命令直接调用其dist产物。这套工作区把可复现的性能实验和可持续的回归守护结合到了一起hyperfine保证统计严谨nx resetNX_NO_CLOUDtrue保证环境纯净goals.jsonbaseline.json双轨对比保证结论可判断而 CI 接入则让性能退化在合并前就被拦截。【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nx CLI 基准测试实战：用 1110 项目合成工作区度量任务流水线性能
Nx CLI 基准测试实战用 1110 项目合成工作区度量任务流水线性能【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nxNx 官方仓库在benchmarks/目录下内置了一套自研基准测试Benchmark工作区它用 1110 个轻量项目模拟超大规模 Monorepo配合 hyperfine 度量 Nx CLI 的启动、项目图构建、任务调度与缓存命中等多个维度的耗时并通过goals.json目标值与本地baseline.json基线形成可量化的性能回归防线。读完本文你将掌握这套基准测试的设计思路、五个bench:*目标的含义、目标/基线对比机制的实现细节以及如何在 CI 中用它守护 Nx 的性能底线。一、基准测试工作区设计三层扇出结构整套基准测试以一个**合成工作区Synthetic Workspace**为载体其结构与真实大型 Monorepo 对齐1110 个项目以三层扇出3-level fan-out排布10 groups × 10 subs × 10 leaves每个项目都定义build、copy、cat三个 target所有 target 都操作同一个共享文件 lorem.md标准 Lorem Ipsum 文本不做真实编译只保留足够的文件 I/O 来考验 Nx 的任务流水线task pipeline。从仓库中的实际项目文件可以清晰地看到这棵依赖树见 benchmarks/packages/group-01、benchmarks/packages/group-01/sub-01组节点 group-01/project.json 只声明name与三个空 target子节点 sub-01/project.json 通过implicitDependencies: [group-01]隐含依赖组节点叶子节点 leaf-01/project.json 同样通过implicitDependencies: [group-01-sub-01]形成三层依赖链。叶子节点的真实名称如group-01-sub-01-leaf-011110 个项目由此生成为run-many -t ...提供了足够的并发规模压力。二、Workspace Targets三个精心设计的测量探针README 用一张表概括了三个 target 的行为详见 benchmarks/README.mdTarget命令缓存输出依赖buildcp lorem.md → dist/output.md是是^buildcopycp lorem.md → copy-out/output.md是是无catcat lorem.md是否无它们的底层实现位于 benchmarks/nx.json 的targetDefaults中关键配置如下{ targetDefaults: { build: { command: mkdir -p {projectRoot}/dist cp lorem.md {projectRoot}/dist/output.md, dependsOn: [^build], cache: true, inputs: [ {projectRoot}/**/*, {workspaceRoot}/lorem.md, { dependentTasksOutputFiles: **/* } ], outputs: [{projectRoot}/dist] }, cat: { command: cat lorem.md, cache: true, inputs: [{projectRoot}/**/*, {workspaceRoot}/lorem.md] }, copy: { command: mkdir -p {projectRoot}/copy-out cp lorem.md {projectRoot}/copy-out/output.md, cache: true, inputs: [{projectRoot}/**/*, {workspaceRoot}/lorem.md], outputs: [{projectRoot}/copy-out] } }, analytics: false, parallel: 5 }从中可以读出三层测量意图build 带拓扑依赖dependsOn: [^build]要求子项目先于父项目构建且dependentTasksOutputFiles: **/*把依赖任务的产物纳入输入哈希专门用来考验 Nx 的拓扑排序 跨任务缓存联动能力README 注明该场景当前在基准列表中处于 disabled 状态即build-warmcopy 带输出追踪有outputs声明可完整走一遍缓存命中 → 恢复输出产物的路径cat 无输出产物cat只有 stdout无输出目录用来测量纯调度 哈希计算的最小开销。此外parallel: 5控制了run-many的并行度整个工作区关闭了 analytics避免遥测干扰测量数据。三、环境准备与快速开始前置依赖基准测试依赖 hyperfine 作为计时工具安装方式cargo install hyperfine同时需要 pnpm仓库根目录使用 pnpm-workspace.yaml 与 pnpm-lock.yaml 管理依赖因为所有命令都通过 pnpm 触发。一键运行全部基准# 运行所有基准并与 goals baseline 对比 pnpm nx run benchmarks单独运行某个基准pnpm nx bench:version benchmarks pnpm nx bench:show-projects benchmarks pnpm nx bench:cat-warm benchmarks pnpm nx bench:copy-warm benchmarks值得注意每个bench:*target 都dependsOn: ^build见 benchmarks/package.json 的nx.targets配置这意味着执行基准前会先编译 Nx 各包——因为基准命令实际调用的是node ../packages/nx/dist/bin/nx.js必须保证产物存在。所有bench:*还都设置了parallelism: false确保基准按序串行执行互不抢占资源。四、五个基准测试详解基准实际执行的命令度量维度versionnx --versionCLI 启动与模块加载耗时show-projectsnx show projects通过 daemon 构建项目图cat-warmrun-many -t cat×1110无输出产物场景下的任务调度 哈希copy-warmrun-many -t copy×1110带输出追踪的缓存任务执行build-warmrun-many -t build×1110带拓扑依赖的缓存任务当前禁用它们在 benchmarks/package.json 的scripts中都有完整定义例如bench:version: NX_NO_CLOUDtrue hyperfine --show-output --setup node ../packages/nx/dist/bin/nx.js reset --warmup 1 --min-runs 10 --export-json results-version.json node ../packages/nx/dist/bin/nx.js --version, bench:show-projects: NX_NO_CLOUDtrue hyperfine --show-output --setup node ../packages/nx/dist/bin/nx.js reset --warmup 1 --min-runs 5 --export-json results-show-projects.json node ../packages/nx/dist/bin/nx.js show projects --tuifalse所有基准遵循相同的测量纪律README 中明确说明统一设置NX_NO_CLOUDtrue彻底隔离 Nx Cloud 网络层只测本地性能每次迭代前通过--setup执行nx reset清空 daemon 与缓存状态保证每次测量都从冷启动开始每个基准至少采集5 次version为10 次取统计值version之外都带 1 次--warmup预热结果以 hyperfine 的--export-json形式写入results-name.json文件。从命令细节还能看出不同基准的差异show-projects使用--tuifalse关闭交互界面而build-warm使用--tuitrue --tui-auto-exit主动开启 TUI 并自动退出用以覆盖 TUI 渲染路径下的真实耗时。五、目标与基线性能回归的双保险性能数据由两个文件共同承载文件是否提交作用goals.json提交committed团队约定的目标耗时CI 中基准超时即失败baseline.jsongitignore本地生成本地机器的个人对比基线goals.json的当前目标值单位为秒max字段{ version: { max: 0.05 }, show-projects: { max: 0.1 }, cat-warm: { max: 0.3 }, copy-warm: { max: 0.5 }, build-warm: { max: 0.75 } }即CLI 启动 50ms 内、项目图构建 100ms 内、1110 个无输出任务 300ms 内、带输出追踪的缓存任务 500ms 内、带拓扑依赖的缓存任务 750ms 内。这些数字直接构成 CI 的硬性回归门槛。设置本地基线# 首次运行会自动创建 baseline.json pnpm nx run benchmarks # 显式用本次结果覆盖基线 pnpm nx run benchmarks -- --set-baseline--set-baseline参数由 run-benchmarks.ts 解析process.argv.includes(--set-baseline)它会将本次五个基准的mean均值写入baseline.json。基线文件是本地专属、不入库的因此换机器后首次运行会自动重新生成这保证了团队内每台开发机都有与自己硬件匹配的参照系。六、执行流程与对比脚本原理README 把整个流程归纳为三步每个bench:*脚本调用 hyperfine生成对应的results-name.jsonruntarget 通过dependsOn依赖全部五个bench:*且它们都parallelism: false按序执行全部完成后run-benchmarks.ts读取结果文件并打印对比表格。runtarget 的依赖顺序在 benchmarks/package.json 中为run: { dependsOn: [ bench:version, bench:show-projects, bench:cat-warm, bench:copy-warm, bench:build-warm ] }对比脚本实现细节run-benchmarks.ts 是整套机制的大脑值得关注的技术点结果读取loadResult()读取results-name.json直接取 hyperfine JSON 中的raw.results[0]包含mean、stddev、min、max时间格式化formatMs()把秒转毫秒≥1s 显示为x.xxs否则显示为xxxms增量计算formatDelta()输出相对百分比如12%彩色对比表表头为Benchmark | Goal | Baseline | Current每个基准行以(goalDelta | baselineDelta)形式展示双重增量——相对目标mean goal.max显示绿色超标显示红色相对基线比基线快 10% 以上ratio -0.1显示绿色慢 10% 以上ratio 0.1显示红色其余为灰色避免微小波动引起噪音健壮性某个results-name.json缺失或损坏时loadResult返回null并跳过该行若一个结果都没有脚本以错误码退出并提示先运行单个基准。对比表同时回答两个问题本次是否突破团队目标对照 goals和相比我本机上次表现如何对照 baseline。七、CI 集成目标即门槛README 明确指出基准测试运行在 CI 的affected target 流水线中nx affected --targets...benchgoals.json中的目标值充当回归闸门regression gate任何一次改动导致对应基准的平均耗时超过goals.json中的max值时CI 即失败。这也是为什么goals.json必须提交入库——它是团队集体认可的性能契约。另外run-benchmarks.ts 对 CI 环境做了专门适配当process.env.CI存在时不会打印To update baseline之类的交互提示保证 CI 输出干净、可解析而在本地运行时脚本会在表格末尾温和提示pnpm bench -- --set-baseline命令注意该提示是脚本内置输出实际更新基线仍应使用 README 中的pnpm nx run benchmarks -- --set-baseline。八、扩展阅读如果想进一步深入这套基准设施建议按以下顺序阅读仓库中的关键文件benchmarks/README.md — 基准测试的总纲与使用入口benchmarks/package.json — 五个基准的 hyperfine 命令与 Nx target 编排benchmarks/nx.json —build/copy/cat三个 target 的targetDefaults与输入/输出/缓存声明benchmarks/run-benchmarks.ts — goals/baseline 对比与彩色表格的完整实现benchmarks/goals.json — 当前性能目标值benchmarks/lorem.md — 所有任务共享的操作文件benchmarks/packages/group-01 与 benchmarks/packages/group-01/sub-01/leaf-01/project.json — 三层扇出项目结构及隐含依赖的样板packages/nx — 被基准的 Nx 核心包源码基准命令直接调用其dist产物。这套工作区把可复现的性能实验和可持续的回归守护结合到了一起hyperfine保证统计严谨nx resetNX_NO_CLOUDtrue保证环境纯净goals.jsonbaseline.json双轨对比保证结论可判断而 CI 接入则让性能退化在合并前就被拦截。【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考