使用 Visual Studio Code 的 Windows 上的 Docker 容器中的 NestJS cli 非常慢

Question

Windows 10 上使用 Visual Studio Code 的 Docker 开发容器中的nestNestJS () 的 cli 命令的响应突然变得非常慢。npm i -g @nestjs/cli起初它工作正常，但在某些时候，例如删除src文件夹中的目录后，nest命令变得非常慢。

\n

例子：

\n

node \xe2\x9e\x9c /workspaces/Servers/terminal-server (master \xe2\x9c\x97) $ time nest --help\n\n[...]\n\nreal    0m44.576s\nuser    0m6.239s\nsys     0m4.407s\n\n

\n

Yarn 用于包管理器。NPM用于全局安装nest cli ( npm i -g @nestjs/cli)：

\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n

软件	版本	在容器中运行	在W10主机上运行
国家公共管理	8.1.2	X
NodeJS	v16.13.1	X
纱	15年1月22日	X
打字稿	4.5.2	X
巢	8.1.6	X
视觉工作室代码	1.63.2		X
Docker 桌面	4.3.1		X

\n

\n

看来是线路const localCommandLoader = local_binaries_1.loadLocalBinCommandLoader();造成/usr/local/share/npm-global/bin/nest了延迟。

\n

编辑：\n编译也很慢。如您所见，它从 8:57:20 开始，到 9:00:17 结束。这是编译默认的脚手架。

\n

[8:57:20 AM] Starting compilation in watch mode...\n\n[8:59:43 AM] Found 0 errors. Watching for file changes.\n\n[Nest] 5197  - 12/23/2021, 9:00:17 AM     LOG [NestFactory] Starting Nest application...\n[Nest] 5197  - 12/23/2021, 9:00:17 AM     LOG [InstanceLoader] AppModule dependencies initialized +67ms\n[Nest] 5197  - 12/23/2021, 9:00:17 AM     LOG [RoutesResolver] AppController {/}: +42ms\n[Nest] 5197  - 12/23/2021, 9:00:17 AM     LOG [RouterExplorer] Mapped {/, GET} route +8ms\n[Nest] 5197  - 12/23/2021, 9:00:17 AM     LOG [NestApplication] Nest application successfully started +8ms\n

\n

我在 WSL 上做了同样的事情：

\n

[10:03:48 AM] Starting compilation in watch mode...\n\n[10:03:53 AM] Found 0 errors. Watching for file changes.\n\n[Nest] 1998  - 12/23/2021, 10:03:54 AM     LOG [NestFactory] Starting Nest application...\n[Nest] 1998  - 12/23/2021, 10:03:54 AM     LOG [InstanceLoader] AppModule dependencies initialized +62ms\n[Nest] 1998  - 12/23/2021, 10:03:54 AM     LOG [RoutesResolver] AppController {/}: +14ms\n[Nest] 1998  - 12/23/2021, 10:03:54 AM     LOG [RouterExplorer] Mapped {/, GET} route +6ms\n[Nest] 1998  - 12/23/2021, 10:03:54 AM     LOG [NestApplication] Nest application successfully started +9ms\n

\n

对于 Docker 映像，我选择了该Node.js & TypeScript映像。仅使用普通映像并手动安装所有内容会更好吗？

\n

或者有没有办法让响应时间恢复nest正常？

\n

Answer 1

TL;DR如果您坚持启动 Windows 进行开发，但想要使用 VSCode 和开发容器，请尝试在 Linux VM 中完成这一切，因为我将关键开发任务步骤所需的时间减少了 96%。

概括

当在 Windows 10 内的 Linux VM 中运行时，与使用 docker 和 wsl2 直接在 Windows 10 中运行 VSCode 相比，开发容器 NestJS TypeScript 项目的启动/重新编译时间减少了 96%。即7s与2m 50snpm run start:dev

开发容器

我认为开发容器很棒，喜欢在 github 代码空间上使用它们，但发现 Win 10 上的体验非常慢。

在多开发人员团队中，开发容器可以在开发人员之间提供一致的体验，并降低不同开发人员机器上不同设置的风险。但是，如果每次在“观看”模式下运行时保存文件都需要花费几秒钟以上的时间来重建应用程序，那么这是毫无价值的。

开发容器中的 NestJS / TypeScript 速度变慢的原因

经过各种调查后，我确信速度损失是在访问主机文件系统的开发容器中。

NestJS cli 令人沮丧地渴望加载它能做的所有事情，甚至在解析命令行参数之前，所以如果文件系统访问很慢，这会是一个很大的打击。

然后 TypeScript 编译显然严重依赖于文件系统速度。这是另一个陷入停滞的领域。即使是在一个相对较小的 NestJS 项目上，几乎没有额外的外部依赖项！

什么最快

在我的 Windows 计算机上的 VM 内运行 Linux，在该 VM 内运行 VSCode 和 docker 意味着在开发容器内（在 Linux VM 内的 docker 中）运行的命令之间的文件系统访问可以访问 Linux VM 上“托管”的代码非常快。

比较表

活动	代码空间 浏览器	Codespaces Win10 远程	使用 WSL2 在 Win 10 上使用VSCode + Win Docker	Win 10 中 Linux VM 中的VSCode + docker
npx nest i	1.16秒	1.16秒	14.2秒	1.12秒
npm run start:dev 启动	10秒	8秒	170年代	7秒
npm run start:dev 更新文件	3秒	2秒	38秒	2秒
rm -rf node_modules ; time npm install	30秒	28秒	85年代	27秒

使用的设置：

• 代码空间
  • 2核4GB实例
• 赢10
  • AMD 锐龙 7 3700X 8 核 @ 4.16GHz
  • 64GB 2400MHz 内存
  • 1TB固态硬盘
  • 互联网：下行 27Mb / 上行 5Mb
• Linux VM（Win 10 以上）
  • 虚拟机16.2.3
  • 乌班图22.04
• dev 容器是推荐的 Node.js 和 Typescript 容器，其变量为：“16-bullseye”
  • 里面运行 mariadb 服务器

为了获得活跃的开发人员体验，我运行每个命令几次，直到时间确定并记录最具代表性的时间......

• 命令中不使用“时间”的任何内容都是手动完成的，因此存在 +/- 1 秒的错误
• time npx nest i
  • 命令最后显示的时间
• npm run start:dev 启动
  • 计时是从按回车键到第一个日志LOG [NestFactory] Starting Nest application...
• npm run start:dev 更新文件
  • 计时是从保存对监视文件的更新到下一个日志LOG [NestFactory] Starting Nest application...
• rm -rf node_modules ; time npm install
  • 只是另一个与文件系统相关的任务来比较环境
  • 命令最后显示的时间