多科回收丨關于減輕服務器負載


去年發現我們的字體服務出人意料的高負載，尤其是晚上沒什么流量的時候。幸運的是，我們發現了這一問題的根本原因，并大幅提升了字體服務的性能和系統整體的穩定性。

用火焰圖調試

我一個同事從 Netflix 公司的 Brendan Gregg 那里發現并部署了一個小巧的火焰圖工具。這個工具可以把多個性能檢測工具的數據結合起來，生成一張本地方法和 JVM 方法資源使用情況的圖象。圖里每一個矩形都代表一個棧幀，矩形的寬度代表資源的使用情況，如 CPU 時間，y 軸代表調用棧。你可以簡單地通過找出比較寬的矩形來定位出問題所在。這個工具對于調試字體服務的性能是非常寶貴的。



我們收集了幾張字體服務高負載狀態下的火焰圖。下面展示了其中一張，圖里有一處 JVM 部分幾乎到頂。我們很快注意到這些圖的規律。絕大部分時間都是消耗在 libz.so（用于 gzip 壓縮和解壓）上，而 JVM 里的絕大部分時間都是消耗在 XML 轉義和 UTF-8 編碼上。



為什么這么慢

首先，介紹一點關于我們字體服務如何工作的背景。我們將字體數據保存在 Amazon S3 容器中，每一種字體的每一 unicode 編碼范圍（unicode range）是一個獨立的對象。其他服務會為字體體系、一系列 unicode 編碼范圍（unicode range）或者用戶來請求字體數據。字體服務會下載用戶請求的字體體系中特定 unicode 編碼范圍（unicode range）的數據，并返回包含這所有數據的 XML。

這一功能非常簡單，并沒有什么明顯密集計算的東西。然而，我們遇到了高負載。我們在火焰圖的幫助下發現 libz、XML 轉義和 UTF8 編碼占用了 CPU 大量資源。但是為什么我們花了這么多時間在編碼和壓縮上呢？記得我剛才說的，晚上負載最高嗎？我們的晚上（美國山區標準時）在亞洲是白天。每當晚上我們本地沒什么流量的時候，大量其他地區的用戶正在用亞洲語言的 unicode 編碼范圍（unicode range），比如中文、日語和韓語。事實上，相比起來這些類別的字體數據是非常龐大的。這些數據通過 gzip 解壓、UTF-8 解碼然后 XML 轉義、UTF-8 編碼最后 gzip 壓縮。對于體積很小的基本拉丁文類別，這一過程沒什么。然而，CJK 類別比基本拉丁文類別大了兩個數量級（1MB 對比 60KB）。對于這些體積大的字體類別，這所有的轉換都使得 CPU 吃不消。Gzip 壓縮和解壓相對很耗資源，XML 轉義也沒有那么快。

怎樣加速

字體服務響應的內容本質上只是來自 S3 的原始數據。字體服務的確做了其他重要的工作，比如權限驗證，查找字體關鍵字。但是沒有理由必須讓字體服務從 S3 轉發字體數據。我們的解決方案非常簡單粗暴，直接返回一系列包含字體數據的 S3 對象的鏈接，而不是通過字體服務下載然后重新編碼字體數據。

這一修改幾乎將字體服務器的負載降為 0（見圖1）。客戶端服務器也察覺不到任何影響。盡管我們第一次嘗試非常成功，但我也應該記住，我們部署的同時增加了功能發布控制，它可以讓我們在 100% 啟用前，先啟用一定比例的請求來測試它能夠正常工作。

結論

通過對生產環境服務器的監控，我們能夠定位并刪除服務器上沒必要的功能。下面是我們這次經歷中幾個關鍵的步驟

用火焰圖等性能檢測工具定位那些霸占 CPU 的功能方法。

壓縮和其他編碼也會非常耗資源。

如果客戶端能夠直接獲取到數據，那么直接發給它一個連接而非轉發數據會提升整體的性能。（聲明：這并不是靈丹妙藥，有些情況下會對客戶端性能造成損失，因為它必須要做二次請求）。