聊聊Flare應用前後端效能優化問題

2022-02-09 19:01:53

寫在前面

在聊 flare 之前，我想先聊聊 flame。

flame 是一個顏值線上的導航頁專案，你可以將你常用的書籤和線上應用儲存在它上面。它由一個波蘭小哥建立，專案地址是 https://github.com/pawelmalak/flame

Flame 預設介面

在試用之後，我覺得專案還不錯，於是稍作調整，封裝了一個新的映象：https://github.com/soulteary/docker-flame

新封裝的應用

在專案檔案中，記錄了我的修改：

簡化程式功能和依賴（如K8S），減少軟體包體積，重構了一些細節邏輯，簡化應用啟動流程。
重寫了天氣獲取邏輯，使用城市名稱替換經緯度來獲取天氣資料。
對程式已有的一些小 BUG 進行了修復，支援中文搜尋。
對程式進行了簡單的漢化。

但是隨著深入使用，我發現頁面有著比較大的效能問題。

因為波蘭小哥採用了 SPA 方案，專案內又包含了 6700 多個 SVG 圖示、以及若干網頁字型，並且在介面上有一些小問題，導致了頁面體積非常大，介面請求數量也非常多。

甚至當你上傳一些包含元素比較多的 SVG 作為你書籤圖示的時候，由 React 觸發的頁面渲染會造成瀏覽器卡死。

我大概有幾百個書籤需要處理，預估未來書籤數量還會增長，所以我使用程式批次建立了接近一千個書籤。然後我發現渲染如此多的書籤，頁面會出現卡頓，甚至在頁面內搜尋包含關鍵詞的書籤也會感受到明顯的掉幀。

所以，我決定重新寫一個輕量一些的程式，來解決我的需求。新的專案地址在這裡，如果你好奇的話，可以試試看：https://github.com/soulteary/docker-flare

製作 flare 的過程，其實也是 flame 效能調優的過程。不過在解決問題之前，我們首先得能定位問題有哪些。

應用效能問題分析

關於這個應用的效能優化，其實並不複雜，和傳統應用優化差別不大：優先減少計算量，在實在減少不了的情況下使用計算效率更高的方式來解決問題。

不過結合使用場景來說，在分析技術問題之前，可以先從功能入手。

對於我不適用的功能

首先從功能上看，我不需要這個應用與 Docker 整合，提供“服務發現”功能。比如在我啟動容器後，這個應用會自動將新啟動的容器作為書籤或者應用進行新增。

其次，在擁有自己的 SSO 服務之後，我也不再需要使用簡單的賬號密碼登入之類的功能，所以這個功能也可以去掉。

最後，關於書籤資料的儲存，我覺得在缺少使用者體驗非常棒的 Web 編輯器的前提下，可能不如設定宣告的方式更易於管理和維護。（你可以使用任何你喜歡的編輯器來更新和維護內容，你可以使用 Git 或者任何你喜歡的方式，以白盒形式儲存你自己的資料）。

基於上面的變化，我大概可以少寫幾個部分的程式碼：容器（Docker & K8S）整合、登入鑑權、應用和書籤，以及書籤分類的 “CRUD”。

前端架構中的問題

Flame 專案中，作者使用都是 create-react-app 腳手架建立的專案，專案依賴為： React v17 + TypeScript + Redux，為了提供簡潔一致的圖示，作者在前端引入了 Templarian/MaterialDesign-JS，一個被精心處理過的 DOM 結構非常簡單的 SVG 圖示庫。

在使用構建工具打包、伺服器端 GZip 壓縮之後，需要傳輸接近 1MB 的資源，原始指令碼程式體積接近 3MB。相對膨大的程式體積導致了頁面載入和執行時間都會比較長。比如頁面頁面首次渲染時間在 1s 上下浮動，多數情況下會超過 1s，完成時間一般都在 1.5s 以上。可能是作者對於伺服器端程式開發不夠熟悉，雖然在前端進行應用設定更新時會複用介面，但是在內容頁面展示時，會呼叫多達8個介面。此外，為了在頁面中展示和更新天氣資訊，波蘭小哥還使用了 WebSocket 來進行資料互動。

Flame 應用效能概覽

其他的問題，在文章前面已經提到過了，就不贅述了。

後端架構中的問題

專案使用的技術棧為 Node.js，Web 框架為市佔率非常高的 Express 的最新版本，ORM 框架選擇的則是 Sequelize，資料儲存落地為 SQLite3 。上面的選擇粗看問題不大，如果應用不需要公開提供瀏覽存取，應該不會出現任何效能問題。

但是，如果我們仔細觀察服務響應，會發現有一些請求的響應的時間非常長，比如頁面資源、比如對於頁面至關重要的 JS 程式資源，它們的獲取都消耗了接近 400ms。

Flame 網路請求記錄

此外，前端發起了多次請求來獲取資料，結合資料儲存使用 SQLite，如果提供公開內容存取，很容易遇到效能瓶頸。

針對應用進行改進

當我們清楚瞭解到上面的問題之後，比如容易採取的方案是：基於原程式進行重構調整，簡化前端請求、合理拆分模組、處理資源載入和執行時機，調整資料儲存和處理方式，提高伺服器端響應能力等組合拳。然而，這會是最簡單和收益最高的方案嘛？

調整前端實現

如果說在需要互動的頁面程式中使用 MVVM 框架會有較高的收益和價效比，那麼在缺少多端元件程式碼複用、沒有伺服器端渲染需求的場景下，使用這類框架則是一個價效比不高的選擇。

或許有同學會問，如果不使用 React、Vue、Angular 這類框架，難道在 2022 年還要再拾起 jQuery 等老的工具嗎？雖然可以，但其實在近乎於純展示的場景下，我們可以脫離 JS 來實現業務功能和簡單的互動，比如自動獲取焦點、選單按鈕的啟用狀態變化、甚至是帶有動畫效果的天氣圖示。

所以，在調整實現的時候，其實還有一個選擇：不使用任何指令碼。

Flare 無指令碼實現的渲染效率

在完成程式之後，我們可以看到從伺服器獲取整個頁面資料、結構解析、樣式計算、元素佈局、頁面繪製的完整時間在 33ms（包含了 idle 等待時間），其中關鍵流程的時間消耗加起來不到 10ms，而完成頁面渲染的時間更是縮短到了 1.65ms。

在得到了頁面快速渲染能力之後，即使不使用瀏覽器針對資源進行快取，加速渲染，我們也能夠做到頁面切換的“無重新整理”瀏覽（因為渲染速度足夠快）。

調整後端實現

雖然我非常喜歡使用 Node.js，以往也分享過你所未知的3種Node.js程式碼優化方式，但是，為了能夠低成本提高高效能的資源響應，這裡進行技術棧切換是必要的：比如 Golang。

在使用 Golang 簡化程式功能後，程式對於每個請求的響應基本能夠保持在幾毫秒的水平（受限於網路傳輸），相比較之前大概下降了2～3個量級。頁面關鍵的 DOM ContentLoad 時間更是縮短到原來的八分之一。

Flare 優化過後批次請求狀況

結合上面的前端優化提到的渲染時間來粗略估計，從資源下載到渲染加起來都不到 10ms，如果不是瀏覽器的一些限制，繪製影格率應該能夠遠超 60 幀，進一步滿足我們實現“即使重新整理了也比沒一些沒重新整理的實現還順滑”。

上面的實現中，我將頁面圖示請求和頁面檔案進行了拆分，在書籤數量和圖示種類不多的場景下，或許並不是最優的方案，但是一旦書籤數量級到幾百、上千之後，你會發現圖示拆分可以極大地提升效能。

當然，為了滿足數量比較少的場景，我也對合並輸出進行了實現，算上網站 favicon 獲取，一共只有兩個請求。在書籤不是很多的時候，渲染效能甚至比檔案和資源拆分輸出效率更好。

Flare 請求合併模式下的網路請求

圖示資源優化

Flame 使用的方案是讀取後端介面設定，從前端指令碼中動態建立 SVG 圖示並插入檔案中，Flare 程式預設的方式則是將 SVG 和檔案拆分，以應對大量書籤狀況下的頁面效能問題。

雖然解決了頁面效能問題，但是伺服器端 IO 問題卻會伴隨而來，所以這裡還需要處理資源在伺服器端的釋放和讀取問題，儘量將資源的磁碟 IO 變為零。

聽起來比較玄乎，但其實結合程式碼生成的方式，還是蠻好實現的。當然，因為 Go 存在自動 GC，所以在不同的資源被使用的時候，會出現大量記憶體的分配，影響效率，這裡可以考慮使用持久化方案來解決問題，處理起來挺有意思的，受限於篇幅和主題就不展開啦。有一部分我在前兩篇文章中提到了，關於 Golang 嵌入資源的使用和優化。

前段時間折騰 Go Emed 的記錄

比如，在不針對 HTTP 服務實現做任何優化、限制執行資源為兩核心的前提下，僅優化資源 IO 後，能達到穩定 3ms 輸出資源，每秒提供2萬7千次以上的響應服務。

容器映象的優化

除了常規優化之外，容器時代的應用，映象優化也是非常關鍵的。容器優化方式，我在前面的文章反覆提過多次，所以也不再展開了，感興趣可以自行翻閱之前的內容。

# docker images | grep fla                 
soulteary/flare       0.1.1      22b18ad73c66        12MB
soulteary/flaume      2.2.0      b39fffc0ca81        152MB
pawelmalak/flame      2.2.0      fa47c93c0af6        179MB
pawelmalak/flame      2.0.0      729b0fcea7f0        190MB

可以看到，相比較原版程式，優化後的程式在本地解壓後的尺寸大概是之前十五到十六分之一。