[rush] rushd: every warm request re-fingerprints the whole workspace (sync file walk, ajv schema recompiles, sync `ps` spawns on the daemon event loop)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- nodejs, typescript
- 领域
- performance, tooling
调研方向
Start by examining the files mentioned: WorkspaceInputFingerprint.ts (lines 62-99, 221-241) for the synchronous file walk and hashing, and LockFile for the ps spawn. Look at how WorkspaceRuntimeFingerprintCache is used and where ajv schema compilation occurs (JsonSchema.ensureCompiled). Profile the daemon with --cpu-prof to see the bottlenecks in action. The fix involves memoizing file stats, caching compiled schemas, and replacing synchronous calls with async or procfs reads. Testing requires a multi-project rush workspace to measure warm request latency before and after changes.
由索引模型根据 Issue 内容生成。
描述
Summary
Most of the daemon-side time for every warm request (tier-0 reuse path) goes to re-fingerprinting the whole workspace from scratch, before anything is scheduled. The cost grows with repo size, and part of the work is synchronous, so it blocks the event loop that serves all clients. After client startup (#6054) is fixed, this becomes the dominant fixed cost of a warm daemon request.
| workspace | captureWorkspaceInputFingerprintAsync (warm median) |
captureProjectConfigurationFingerprintAsync (median) |
sync runtime _hashPaths |
|---|---|---|---|
| 30-project synthetic | 61 ms | 22 ms | 22-27 ms |
| rushstack (196 projects) | 263 ms | 372 ms | 23 ms |
Fully warm no-op latency vs graph size (synthetic): 1.26 s at 1 project, 2.84 s at 50, 8.67 s at 300. That is about 25 ms per project, bound by re-validation. A daemon CPU profile over 12 warm requests in a 30-project workspace shows:
- lstat 466 ms and realpath 263 ms (from
_hashPaths/hashFilesAsync); - ajv schema compilation 530 ms (
JsonSchema.ensureCompiledvia heft-config-file: uncached project config loads recompile the schemas); LockFile.tryAcquire -> getProcessStartTime -> spawnSync('ps')353 ms, about 30-54 ms per call. It runs on every request (acquireExecutionLeaseAsync), in warm-set maintenance, and in#prepareAsync.
As a result, the daemon event loop stalls for up to 190-260 ms (p99) while preparing warm requests, delaying every other client.
Repro steps
Call the same rush-lib functions that WorkspaceRequestLifecycle calls on the tier-0 path (#captureAsync at WorkspaceRequestLifecycle.ts:373 and captureProjectConfigurationFingerprintAsync at :384), with a persistent WorkspaceRuntimeFingerprintCache, 10 times against a 30-project and a 196-project workspace. Or profile the daemon (--cpu-prof) during repeated warm no-op rush-client build requests.
Expected result: Warm requests do incremental work proportional to what changed: stat-identity memoization of definition files, cached compiled schemas, and cached runtime fingerprints. Nothing synchronous or subprocess-based sits on the daemon event loop per request.
Actual result: Full recomputation on every request, with a synchronous file walk, schema recompiles, and a synchronous ps spawn.
Details
Root cause (main @ 60007c9a8c):
libraries/rush-lib/src/api/WorkspaceInputFingerprint.ts:62-99(_hashPaths): a synchronous recursive readdir plusstatSync/realpathSyncof the ~500+ runtime files on every capture.:221-241(hashFilesAsync): re-reads and re-hashes every definition file (rush.json, common/config/**, 4 files per project) with concurrency 3, with no stat memo.:199-215(captureProjectConfigurationFingerprintAsync): uncached project configuration loads recompile ajv schemas.LockFilegetProcessStartTimespawnspssynchronously. On Linux, read/proc/<pid>/statinstead.
Suggested fix: memoize by file identity (dev/ino/size/mtime/ctime), making hashes a cheap stat check; cache compiled schemas process-wide; compute the runtime fingerprint once per process, since runtime files cannot change without a restart; replace the synchronous ps with procfs; and move the remaining synchronous I/O off the event loop.
This was found during an automated performance/behavior analysis of rush-client/rushd on Linux and independently confirmed.
Standard questions
| Question | Answer |
|---|---|
@microsoft/rush globally installed version? |
built from main @ 60007c9a8c (5.179.0) |
rushVersion from rush.json? |
5.179.0 |
pnpmVersion, npmVersion, or yarnVersion from rush.json? |
[email protected] |
(if pnpm) useWorkspaces from pnpm-config.json? |
true |
| Operating system? | Linux (WSL2 Ubuntu 24.04) |
| Would you consider contributing a PR? | Yes |
Node.js version (node -v)? |
22.23.2 |
- 主要语言
- TypeScript
- 星标
- 6.5k
- 派生
- 708
- 平均合并
- 4 天 13 小时
- 30 天内合并 PR
- 62
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/rushstack 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
microsoft/rushstack#5971 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
microsoft/rushstack#5902 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/rushstack#5839 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
microsoft/rushstack#5683 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
查看 microsoft/rushstack 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
diegosouzapw/OmniRoute#14869 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 94/100
维护者通常 1 天内回复
-
status: waiting triage
难度 2/5 1-3 小时 新手友好度 84/100
freeCodeCamp/freeCodeCamp#70412 ·
维护者通常 1 天内回复
-
Mend: dependency security vulnerability untriaged
难度 1/5 1 小时以内 新手友好度 88/100
opensearch-project/OpenSearch-Dashboards#12816 ·
维护者通常 1 天内回复