這些基準測試有必要性，因為我們需要一個簡單、可復現的方式來衡量性能。但基準測試也有局限性，因為每一次基準測試都有其限定的運行環境和軟硬體配置，這些配置設定對性能的影響可能很大，同時這些軟硬體配置是否符合企業需求、是否具有代表性，都是需要考慮的問題。

阿里的數據中心裡有上萬種不同的業務應用，也有上百萬台分布在世界各地的不同伺服器。當我們考慮在數據中心裡升級改造軟體或硬體時，一個關鍵問題是小規模基準測試的效果是否能擴展到數據中心裡複雜的線上生產環境？

舉個例子，我們開發了 JVM 的一個新特性，在 SPECjbb2015 的基準測試中看到了不錯的性能收益，但到線上生產環境灰度測試的時候，發現該特性可以提升一個 Java 應用的性能、但會降低另一個 Java 應用的性能。同時，我們也可能發現即便對同一個 Java 應用，在不同硬體上得到的性能結果大不相同。這些情況普遍存在，但我們不可能針對每個應用、每種硬體都跑一遍測試，因而需要一個系統化方法來估計該特性對各種應用和硬體的整體性能影響。

對數據中心來說，評估每個軟體或硬體升級的整體性能影響非常重要。比如，「雙11」的銷售額和交易峰值，業務層面可能主要關心這兩個指標，那麼這兩個指標翻一倍的時候我們需要買多少台新機器？需要多買一倍的機器么？這是衡量技術能力提升的一個手段，也是體現「新技術」對「新商業」影響的一個途徑。我們提出了很多技術創新手段，也發現了很多性能提升的機會，但需要從業務上也能看出來。

為了解決上面提到的問題，我們開發了 SPEED 平台。首先是估計當前線上發生了什麼，即 Estimation，通過全域監控採集數據，再進行數據分析，發現可能的優化點。比如，某些硬體整體表現比較差，可以考慮替換。

然後，我們會針對軟體或硬體的升級改造做線上評估，即 Evaluation。比如，硬體廠商推出了一個新硬體，他們自己肯定會做一堆評測，得到一組比較好的性能數據，但剛才也提到了，這些評測和數據都是在特定場景下跑出來的，這些場景是否適合用戶的特定需求？

沒有直接的答案。通常，用戶也不會讓硬體廠商到其業務環境里去跑評測。這時候就需要用戶自己拿這個新硬體做灰度測試。當然灰度規模越大評測越準確，但線上環境都直接關聯業務，為了降低風險，實際中通常都是從幾十台甚至幾台、到上百台、上千台的逐步灰度。SPEED 平台要解決的一個問題就是即便在灰度規模很小時也能做一個較好的估計，這會節約非常多的成本。

隨著灰度規模增大，平台會不斷提高性能分析質量，進而輔助用戶決策，即 Decision。這裡的決策不光是判斷要不要升級新硬體或新版軟體，而且需要對軟硬體全棧的性能有一個很好的理解，明白什麼樣的軟硬體架構更適合目標應用場景，這樣可以考慮軟硬體優化定製的方向。

比如，Intel 的 CPU 從 Broadwell 到 Skylake，其架構改動很大，但這個改動的直接效果是什麼？Intel 只能從基準測試中給答案，但用戶可能根據自己的應用場景給出自己的答案，從而提出定製化需求，這對成本有很大影響。

最後是 Validation，就是通常規模化上線後的效果來驗證上述方法是否合理，同時改進方法和平台。

數據中心裡軟硬體升級的性能分析需要一個全局的性能指標，但目前還沒有統一的標準。Google 今年在 ASPLOS 上發表了一篇論文，提出了一個叫 WSMeter 的性能指標，主要是基於 CPI 來衡量性能。

在 SPEED 平台里，我們也提出了一個全局性能指標，叫資源使用效率 RUE。基本思想很簡單，就是衡量每個單位 Work Done 所消耗的資源。這裡的 Work Done 可以是電商里完成的一個 Query，也可以是大數據處理里的一個 Task。而資源主要涵蓋四大類：CPU、內存、存儲和網路。通常我們會主要關注 CPU 或內存，因為目前這兩部分消費了伺服器大部分的成本。

RUE 的思路提供了一個多角度全面衡量性能的方法。舉個例子，業務方反映某台機器上應用的 response time 升高了，這時登錄到機器上也看到 load 和 CPU 利用率都升高了。這時候你可能開始緊張了，擔心出了一個故障，而且很可能是由於剛剛上線的一個新特性造成的。

然而，這時候應該去看下 QPS 指標，如果 QPS 也升高了，那麼也許是合理的，因為使用更多資源完成了更多的工作，而且這個資源使用效率的提升可能就是由新特性帶來的。所以，性能需要多角度全面地衡量，否則可能會造成不合理的評價，錯失真正的性能優化機會。

下面具體講幾個數據中心性能分析的挑戰，基本上是線上碰到過的具體問題，希望能引起大家的一些思考。

首先是性能指標。可能很多人都會說性能指標我每天都在用，這有什麼好說的。其實，真正理解性能指標以及系統性能本身並不是那麼容易。舉個例子，在數據中心裡最常用的一個性能指標是 CPU 利用率，給定一個場景，數據中心裡每台機器平均 CPU 利用率是 50%，假定應用需求量不會再增長、並且軟體之間也不會互相干擾，那麼是否可以把數據中心的現有機器數量減半呢？

這樣，理想情況下 CPU 利用率達到 100% 就可以充分利用資源了，是否可以這樣簡單地理解 CPU 利用率和數據中心的性能呢？肯定不行。就像剛才說的，數據中心除了 CPU，還有內存、存儲和網路資源，機器數量減半可能很多應用都跑不起來了。

再舉個例子，某個技術團隊升級了其負責的軟體版本以後，通過線上測試看到平均 CPU 利用率下降了 10%，因而聲明性能提升了 10%。這個聲明沒有錯，但我們更關心性能提升以後是否能節省成本，比如性能提升了 10%，是否可以把該應用涉及的 10% 的機器關掉？這時候性能就不應該只看 CPU 利用率，而應該再看看對吞吐量的影響。

所以，系統性能和各種性能指標，可能大家都熟悉也都在用，但還需要更全面地去理解。

剛才提到 SPEED 的 Estimation 會收集線上性能數據，可是收集到的數據一定對嗎？這裡講一個 Hyper-Threading 超線程的例子，可能對硬體了解的同學會比較熟悉。超線程是 Intel 的一個技術，比如我們的筆記本，一般現在都是雙核的，也就是兩個 hardware cores，如果支持超線程並打開以後，一個 hardware core 就會變成兩個 hardware threads，即一台雙核的機器會有四個邏輯 CPU。

來看最上面一張圖，這裡有兩個物理核，沒有打開超線程，兩邊 CPU 資源都用滿了，所以從任務管理器報出的整台機器平均 CPU 利用率是 100%。左下角的圖也是兩個物理核，打開了超線程，每個物理核上有一個 hardware thread 被用滿了，整台機器平均 CPU 利用率是 50%。

再看右下角的圖，也是兩個物理核，也打開了超線程，有一個物理核的兩個hardware threads 都被用滿了，整台機器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情況完全不同，但是如果我們只是採集整機平均 CPU 利用率，看到的數據是一樣的！

所以，做性能數據分析時，不要只是想著數據處理和計算，還應該注意這些數據是怎麼採集的，否則可能會得到一些誤導性的結果。

數據中心裡的硬體異構性是性能分析的一大挑戰，也是性能優化的一個方向。比如這裡左邊的 Broadwell 架構，是 Intel 過去幾年伺服器 CPU 的主流架構，近幾年在推右邊的 Skylake 架構，包含最新的 Cascade Lake CPU。Intel 在這兩個架構上做了很大的改動，比如，Broadwell 下訪問內存還是保持多年的環狀方式，而到了 Skylake 改為網格狀方式。

再比如，L2 Cache 到了Skylake 上擴大了四倍，通常來說這可以提高 L2 Cache 的命中率，但是 cache 越大也不代表性能就一定好，因為維護 cache coherence 會帶來額外的開銷。這些改動有利有弊，但我們需要衡量利和弊對整體性能的影響，同時結合成本來考慮是否需要將數據中心的伺服器都升級到 Skylake。

了解硬體的差異還是很有必要的，因為這些差異可能影響所有在其上運行的應用，並且成為硬體優化定製的方向。

現代互聯網服務的軟體架構非常複雜，比如阿里的電商體系架構，而複雜的軟體架構也是性能分析的一個主要挑戰。舉個簡單的例子，圖中右邊是優惠券應用，左上角是大促主會場應用，左下角是購物車應用，這三個都是電商里常見的業務場景。從 Java 開發的角度，每個業務場景都是一個 application。電商客戶既可以從大促主會場選擇優惠券，也可以從購物車裡選擇優惠券，這是用戶使用習慣的不同。

從軟體架構角度看，大促主會場和購物車兩個應用就形成了優惠券應用的兩個入口，入口不同對於優惠券應用本身的調用路徑不同，性能影響也就不同。

所以，在分析優惠券應用的整體性能時需要考慮其在電商業務里的各種錯綜複雜的架構關聯和調用路徑。像這種複雜多樣的業務場景和調用路徑是很難在基準測試中完全復現的，這也是為什麼我們需要做線上性能評估。

這是數據分析里著名的辛普森悖論，在社會學和醫學領域有很多常見案例，我們在數據中心的性能分析里也發現了。這是線上真實的案例，具體是什麼 App 我們不用追究。

假設還用前面的例子，比如 App 就是優惠券應用，在大促的時候上線了一個新特性 S，灰度測試的機器佔比為 1%，那麼根據 RUE 指標，該特性可以提升性能 8%，挺不錯的結果。但是如果優惠券應用有三個不同的分組，分組假設就是關聯剛才提到的不同入口應用，那麼從每個分組看，該特性都降低了應用的性能。

同樣一組數據、同樣的性能評估指標，通過整體聚集分析得到的結果與通過各部分單獨分析得到的結果正好相反，這就是辛普森悖論。既然是悖論，說明有時候應該看總體評估結果，有時間應該看部分評估結果。在這個例子裡面，我們選擇看部分評估、也就是分組上的評估結果，所以看起來這個新特性造成了性能下降，應該繼續修改並優化性能。

所以，數據中心裡的性能分析還要預防各種可能的數據分析陷阱，否則可能會嚴重誤導決策。

最後，還有幾分鐘，簡單提一下性能分析師的要求。這裡通常的要求包括數學、統計方面的，也有計算機科學、編程方面的，當然還有更重要的、也需要長期積累的領域知識這一塊。這裡的領域知識包括對軟體、硬體以及全棧性能的理解。

其實，我覺得每個開發者都可以思考一下，我們不光要做功能開發，還要考慮所開發功能的性能影響，尤其是對數據中心的整體性能影響。比如，JVM 的 GC 開發，社區里比較關心 GC 暫停時間，但這個指標與 Java 應用的 response time 以及所消耗的 CPU 資源是什麼關係，我們也可以有所考慮。

本文作者：郭健美

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

本文來自雲棲社區合作夥伴「 阿里技術」，如需轉載請聯繫原作者。

推薦閱讀：