借助 RAM disk 技术，加快前端工程打包速度

 

背景
以 Jenkins 服务器为例，在构建内部的这个项目时，CE 每部署一次服务，最快 6 分钟，最
慢将近 13 分钟左右。遇到多个项目并发打包会由于资源占用等问题时间会延长，甚至出现过
几回 20 分钟以上的状况。

 

因此常常收到一些友情提示：好比像这样的截图，每每对方只发一张图，却什么都不说：

 

缘由
在了解缘由以前，咱们先回顾一下历史，也就是当年为何要用 Yarn。从这段历史中，咱们
能够分析出来慢的缘由。

Yarn 工具没有推出以前，一般是使用 NPM 进行依赖管理的，早期的 NPM 它有一个致命的
缺陷；须要等一个包，彻底安装好后，在对下一个包作处理；它没有并发能力，因此才不会
涉及到高 IO 的问题，牺牲的是等待时间。

NPM 遇到相同版本的依赖库时，会从新下载一遍这个包；由于它原生不具有缓存能力，因此
只能从新下载。这也不会涉及 IO 问题，由于它牺牲了下载时间和 node_modules 文件夹的体
积（这里是提早引用概念，下面第四条中有介绍）。

 

因此当时，咱们引用了 Yarn 工具来提高安装依赖的速度。

(1) 它最特殊的是，具有锁（lock）文件，你从哪下载文件，你团队的人就从哪下载文件，避
免包版本不一致的问题。能解决我线下好使啊，怎么到你那就不行，诸如此类的问题。

(2) 会缓存它下载的每一个包，因此无需重复下载。

(3) 具有离线模式，以前安装过的包会被写入缓存目录，之后安装就直接从缓存中复制过来，
这样作的本质是减小重复下载，减小没必要要的网络请求。

(4) 为了减小 node_modules 体积，会对依赖次数作选举，把引用频率高的类库放到顶级目录。

 

咱们已经了解，它是依赖文件缓存的方式，提高了效率问题；仅仅是作选举，就已经引起了
高频 IO 的操做，由于它要分析引用次数来回的移动目录。Webpack 打包构建状况也是相似，
具体就不在展开细说。

 

现象
因此咱们有了一个印象，前端工程下载后，会作不少 IO 操做。这对 SSD 磁盘颇有效。若是
是机械硬盘，遇到高频读写，性能就会很慢。这是 Yarn 在作依赖库选举而优化磁盘占用时，
机械硬盘所消耗的时间耗时 13 分钟：

这种状况咱们很难避免，只有几种选择：
1. 后退，使用 NPM 工具，选择等待牺牲网络下载时间，这条路走不通。
2. Jenkins 更换 SSD 磁盘，更换硬件其实是最好的方案，短时间内也走不通。
3. 优化 Yarn 依赖库的选举方案，Yarn PnP 还不太成熟，咱们还在调研中，有坑，也走不通。

解决方案
当时的状况是，正常的方案都没法走通了。直到有一天个人同事提供一个思路，说他当年在 Windows
下片时，为了加快 Copy 速度把内存当磁盘用了，Windows 设置这个东西很简单。大家看看
Linux 支不支持。随后咱们就开始调研，本机测试后发现可行。

而后咱们以线下的的环境作试点，部署脚本改好了测试近一周，发现可行。

 

优化前，最高 23 分钟（开篇第一张图），如今平均 3 分钟：

另外一个项目优化前，平均 8 分钟：

优化后，平均 49 秒：

 

本次主要是给你们，提供一个解决 IO 问题的思路。咱们使用的是 RAM disk 中的 temfs
方案。技术对比看下方连接的文章就行，很简单：

 

参考连接
https://baike.baidu.com/item/tmpfs/1476960?fr=aladdin
https://blog.csdn.net/wz947324/article/details/80007122