背景
以 Jenkins 伺服器為例，在構建內部的這個專案時，CE 每部署一次服務，最快 6 分鐘，最
慢將近 13 分鐘左右。遇到多個專案併發打包會因為資源佔用等問題時間會延長，甚至出現過
幾次 20 分鐘以上的情況。

所以經常收到一些友情提示：比如像這樣的截圖，往往對方只發一張圖，卻什麼都不說：

原因
在瞭解原因之前，我們先回顧一下歷史，也就是當年為什麼要用 Yarn。從這段歷史中，我們
可以分析出來慢的原因。

Yarn 工具沒有推出之前，通常是使用 NPM 進行依賴管理的，早期的 NPM 它有一個致命的
缺陷；需要等一個包，完全安裝好後，在對下一個包做處理；它沒有併發能力，所以才不會

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/8000