藉助 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