無論是在個人的本地電腦，還是在團隊的區域網專有伺服器上，快取伺服器都能通過優化資源匯入過程讓使用Unity開發的速度變得更快。遠端快取伺服器Cache Server 6.0版本現已釋出，快取伺服器的質量和效能獲得大幅提高。

這次的改進十分龐大，下面將由Asset Bundles研發主管Stephen Palmer為大家介紹詳情。

訪問GitHub下載Cache Server 6.0：
https://github.com/Unity-Technologies/unity-cache-server

 

快取伺服器解決了哪些問題？
在使用Unity編輯器時，每次增加或修改專案中的資源時，都必須進行一次匯入過程。當參與Unity的開發團隊逐漸壯大時，這樣會產生二個問題：

• 專案中會有更多資源。
• 資源會更頻繁地被修改。

由於Unity編輯器需要不斷計算並匯入專案變更，你和團隊成員會浪費大量寶貴的開發時間。對於多平臺的專案而言，這個問題還會更為複雜。因為在切換目標平臺時，所有專案中依賴平臺的資源，例如紋理、音訊都會重新進行轉換，這個過程在大型專案中甚至會耗費多達幾個小時。

為了加快這個過程的完成速度，資源快取伺服器可以部署在本地系統供個人使用，也可以部署在區域網或廣域網環境下，方便團隊合作完成專案。Unity編輯器會使用資源快取服務來儲存和恢復多個平臺的資源形式，同時分攤整個團隊中的資源匯入成本。

快取伺服器的目標
我們從不少開發者處得知，在使用快取伺服器時，他們遇到了諸如效能低下等問題。很明顯，快取伺服器的架構已受制於其最初的設計，需要進行特別處理使其能符合當前Unity架構和質量標準。

在本文中，將講述我們通過效能檢測、障礙識別和目標修復來為我們的開發人員儘快提供改進結果。

效能測試

• 一個用Python編寫的綜合測試客戶端，用於模擬超大流量，它的PUT/GET大小和併發連線數都是可配置的。
• 在多個Mac OS和Windows下測試Unity編輯器，使用Python客戶端和Unity編輯器客戶端來模擬載入過程。
• 一系列演示專案，特別是《Adam》內部和外部環境專案以及在我們支援庫中的大型客戶專案。

我們對連線快取伺服器的單個Unity編輯器進行了測試，伺服器和編輯器執行在同一系統上，也在千兆以太區域網上將快取伺服器作為託管伺服器執行並測試。

在託管伺服器上，我們測試了以下幾種情況：

• 二個通過乙太網連線的Unity編輯器客戶端。
• 二個通過Wi-Fi連線的Unity編輯器客戶端。
• 由Python綜合指令碼客戶端和Unity編輯器客戶端組成的大量客戶端（不少於12個客戶端）。

效能測試結果
測試的結果十分明顯。連線到本地伺服器的單個Unity編輯器客戶端沒有發現問題，總體效能不錯。在廣域網上連線的二個客戶端也表現得很好。

問題就發生在使用Wi-Fi連線的客戶端，它們在大型綜合測試時幾乎無法使用。伺服器查詢、客戶端斷開連線等一些失敗情況會更為頻繁而快速地出現。我們需要弄清楚這些問題產生的原因。

程式碼測試結果
快取伺服器是一個Node.JS伺服器應用，它對於I/O為中心的應用來說是個具有高度可擴充套件性的平臺，它比我們在這所測試的多個併發客戶端要好。所以問題出現在哪呢？

比較明顯的幾個問題：

• 程式碼缺乏自動測試套件。沒有測試元件的話，要想在安全地對其更改以便進行效能改進測試，這幾乎是不可能的事。而且，還有一些隱藏錯誤導致了一些已發現的問題。
• 大量I/O同步檔案呼叫。首先Node.JS是單執行緒的。其次，雖然Node.JS的檔案系統支援同步和非同步方式，我們原來主要採用的是同步操作。因此，呼叫或是進行CPU密集型任務會很快降低整個伺服器的效能。
• 在整個快取大小超過限制時，伺服器釋放空間的方法十分消耗資源，並且會觸發對整個目錄的遍歷，使所有新檔案都被寫入快取中。
• 管理協議處理和檔案系統快取的程式碼互相交織，使得在對特定目標進行優化時，很難隔離其它系統。

效能改進實驗
在對特定問題進行處理前，我們對一些優化策略進行了預估。然後做了一些快速實現來評估它們所產生的影響。
 

• 更新優化：我們製作了一個快速方法，用來儘可能多地移除同步呼叫，然後改進了一些庫的用法。
• 叢集：我們實現了Node.js的叢集，它將伺服器分成可配置數量的離散程序。
• 緩衝：我們試著通過緩衝套接字的寫入來消除從伺服器上傳客戶端時的套接字延遲。
• “快取到快取”：我們實現了一個記憶體快取，裡面包含小型的（大小可配置，但目標小於64KB）快取物件，從而減小了檔案系統I/O。

這些測試的結果和觀測如下：

• 更新優化和叢集：在大量測試負載下，測試結果顯示了更高的穩定性。它不會崩潰或是凍結，也沒有與連線超時的伺服器斷開連線。
• 緩衝：這個方法的結果比較複雜。綜合測試表現出了一定的改善效果，但是實際的客戶端測試則不一定。在Cache Server 6.0中，我們充分利用了Node.JS流架構來確保客戶端和伺服器之間的資料流儘可能高效。
• “快取到快取”：這項優化在綜合測試中效果拔群，但在實際的客戶端測試中略有遜色。這種差異是因為一些綜合測試使用了小型的標準資源，這類資源很適合這項優化策略。而實際客戶端則更多地會有一些未排序資源大小，所以造成了二個結果的差異。

第一階段更新 : Cache Server 5.4
基於這些實驗，我們決定分二個階段進行改進。在第一階段，我們會先處理比較簡單的問題，並對程式碼進行修改以方便以後的改進。
 

• 為了提高錯誤修復的部署速度、使其擁有更快的釋出週期和直接的社群貢獻，我們將這部分開發移至GitHub上，程式碼在Apache 2.0協議下開源。
• 我們實施了一套完整的測試套件，它能測試出一些重要的錯誤。
• 增加了Node.JS叢集支援，所有檔案I/O操作都會與主要工作部分相隔離。在高負載情況下，這會大幅提升穩定性和效能。
• 為了方便進行維護，我們重構了程式碼，將程式碼中的協議和檔案系統功能分離開。

在最初的效能調查完成後，僅過了2周，快取伺服器Cache Server 5.4便於去年九月釋出。而且，在此過程中發現的錯誤修復會被回退到Unity 2017.2時釋出的快取伺服器版本。自從Cache Server 5.4版釋出後，我們收到了大量來自開發者的積極反饋，他們在此之前都遇到了快取伺服器的問題。

第二階段更新 :Cache Server 6.0
自從Cache Server 5.4釋出以來，我們一直在從頭開始重建快取伺服器，為了可維護性和未來改進打下更好的基礎。我們還希望對最為苛刻的企業環境提供高階解決方案，這些企業環境當前正部署和維護他們自行定製的快取伺服器解決方案。

Cache Server 6.0有更高的可靠性和效能，還有一些新功能，包括：

• 除了標準檔案系統後端快取模組外，還增加了高效能記憶體（RAM）快取模組。
• 事務映象功能，用於自動同步對一個或多個下屬快取伺服器的更改。
• 一個專案匯入工具，可以用於從已有完全匯入的Unity專案中快速獲取快取伺服器。

小結
快取伺服器Cache Server 6.0就介紹到這裡，希望它能夠幫助到Unity的開發人員提高使用Unity進行開發的工作效率，趕緊下載進行使用吧! 更多Unity的新功能介紹，盡在 Unity中文官方論壇(UnityChina.com) ！