性能测试真如你想象的那么简单？
我是阿里云彈性計算性能測試負責人西邪。
我從 2018 年開始組建阿里云彈性計算的性能測試團隊，從要一周完成一組性能測試，到只需 1 分鐘就可以觸發一組全自動性能測試，到最后結果整理一鍵搞定，內部命名為開天斧。
現在開天斧已經承擔整個彈性計算所有的性能測試工作：新技術、新設備、新規格等等，保證了線上的性能穩定性。在性能測試的同時，還要負責解決客戶的性能問題。期間還負責了“變形金剛”這個項目，把物理機的底層資源管理產品化了，使得現在線上千變萬化的規格，只需一個模板就可以簡單實現。
這里就先跟大家分享下這 3 年在性能測試上的一些收獲。
什么是性能測試？
性能測試不同于功能測試，功能測試驗證的是某個功能是否完成，性能測試驗證的是某個性能是否達到。
驗證性能就需要很多性能“標尺”，如衡量 CPU 性能：通過 SPEC CPU，UnixBench 等；衡量網絡性能用 netperf，iperf，sockperf 等等；衡量存儲性能最好用的是 fio，衡量內存帶寬性能則是 stream。
上述說的都 micro Benchmark，通常如果某塊做的不好，就可以直接提缺陷給相關的團隊去優化；而客戶實際感知的是真實業務場景，那就需要去模擬客戶的場景，比如客戶經常使用的是 nginx，redis，MySQL 等，通過實際的場景測試，來驗證當前服務器的優劣。通過做好性能測試，才能建立自己的底氣，做好性能分析，才能知道哪里薄弱，從而往哪里發力！
性能測試要做哪些？
性能的重要性無需多言，我就直接略過了。一個服務器有 5 大塊：CPU、內存、存儲、網絡、OS。對，就是驗證這些模塊的性能，上面也簡單介紹了下該用哪些工具進行性能測試。但是對于性能測試而言，如果僅僅是一個測試，那太簡單了，實際上還需要考慮很多。
性能主要可以看以下幾個方面：
可能光談問題還是抽象了點，我再具體舉幾個例子。
先談與 CPU 相關：
● Intel、AMD、ARM 差異？指令差異
● CPU 不同代數差異
● CPU 主頻、基頻、睿頻、P0-n、P0-1
● CPU 是否 PIN 住
● 超線程開關：底層開關、OS 開關
● NUMA 架構：membind、interleave...
● 電源策略: performance、powersave、C-State 聯系
● TDP: 睿頻不符預期時看下 TDP 是否限制住了，很有用！
● L3 Cache 大小
● 內存帶寬、內存時延
● OS：內核版本、CPU 漏洞開關
● CPU 微碼
● 軟件：glibc 版本等
● 不同版本、特殊編譯器：AOCC、icc
上面的這些都是 CPU 需要具備的基礎知識，甚至還需要深入底層去看問題，比如看底層 CPU 的 PMU 相關的一些東西。同樣其他模塊知識也是必不可少的。
除了知識具備外，每個模塊測試完備性也很重要，比如分析網絡性能數據，重點看下面這些性能：
● 網絡帶寬：多流、單流
● 網絡 PPS：多流、單流
● 網絡 session 連接數
● 網絡新建連接數
● 網絡時延
● 網絡長連接、網絡短連接性能
● 網絡并發性能：上述性能在多個機器的情況下，并發效果能否延續
● 網絡性能穩定性：網絡壓力變大（pps 變大或者帶寬變大或者 session 數變大），時延的穩定性
● 網絡丟包率、重傳率
網絡性能數據出來后，那這些數據又怎么看呢？下圖是一個常見分位圖：
絕大多數情況，在分析定義一個數據的時候，不能單單看 min、average、max，倒是分位數性能數據非常重要，還有波動率。
如果這些問題你都能很好回答，想必你就是一位功力深厚的大俠了。
為什么性能測試沒那么簡單？
性能測試如果僅僅是一個測試，還算簡單。當然復雜的測試也很復雜，比如干擾測試（模擬吵鬧鄰居）。但總的測試而言，就是一個工程自動化，效率提升的手段。
那難在哪里？
難在上節的話題能否執行到位。比如內存時延，在 Intel 的 CPU，整機情況下是 2 個NUMA NODE，底層是 2 個 CPU，那么需要考慮當前 Node 的內存時延，以及跨 Node 的內存時延。知道這些后，那么后面應用表現出來的現象才可能有相關解釋。
舉個例子，把一個性能測試步驟分解開來，如下：
這里只有一個環節：test 環節，需要的功力淺。這存在一個誤解，很多人以為性能測試就是 “test” 這一環節，當然不是！
breakdown，design，analyse，如果不是一個經驗豐富的性能工程師，怎么可能 breakdown，desgin，甚至 analyse。
舉個例子：Intel Cascadelake CPU 性能測試。breakdown 的時候，你需要很多背景知識，這些背景知識會決定你后面的性能分析預期。
等等......
接下來是性能測試，在測試一個系列的性能測試時，需要一套完整的性能測試方案，做個全方面的對比。這塊業界只有 SPEC CPU，SPEC JBB，UnixBench 等一套成熟的 CPU 性能測試，但是沒有完備服務器性能測試方案，這使得客戶上云變得很迷茫，怎么全面衡量云服務器的性能呢？這些都需要積累豐富，并形成一個完整體系。
等到性能測試結束，就需要去做性能分析，之前講了如何看網絡性能數據，但有時也會有些奇怪的數據需要去解釋。
舉個實際例子：比如網絡單流的性能測試。有時候會發現波動很厲害，起先以為是網絡性能不穩定，后經過實際排查，發現有概率發生中斷的 CPU 與網絡進程所在 CPU 在同一個核的時候，性能就會非常差，通過 taskset 硬性隔離開，中斷和網絡測試進程分別在不同的 CPU 上，網絡單流性能就上去了且穩定。
所以，性能測試難就難在知識儲備夠不夠厚、能否充分理解業務性能、性能設計以及最終的性能分析，以及對于數據結果預期的確定等，這些都非一朝一夕之功！
那有什么破解之法呢？我認為主要有三點：
好學：如果把一個業務系統從上到下去分析，每一個都可以發展開來：業務架構、OS、一門語言、底層虛擬化、CPU 微架構都是值得學習。推薦《性能之巔》這本書，可以領你入門。
勤：每一個 Case 都是一次機會，值得好好去研究。
鉆研：肯定會遇到問題，遇到問題不拋棄不放棄，發揚 Geek 精神！
性能測試人員需要具備的基本技能
文章最后，再分享下我認為性能測試人員應該具備的基本技能。
計算機體系知識：計算機組成原理、操作系統、編譯原理、計算機網絡、軟件測試、Linux 內核分析... 大學的課程都需要了。不但要有書本知識，還能結合實際問題進行分析。
架構思維：任何一個需求，問題，都需要站在一個很高的位置去審視問題，去思考如何設計；特別是客戶的問題，當前架構是否合理，出現這個問題有哪些方向。
自動化測試：如何把這些手工的測試自動化，是解放生產力必須的，同時才能輕松去完成線上巡檢。針對特殊問題，還需要具備構建特殊的測試案例能力。
分析技巧：應該熟練掌握各種性能分析的工具：top、vmstat、mpstat、pidstat、iostat、sar、火焰圖等，高階如 BPF 技巧。
實際工作經驗：這個在設計 Case 的時候太重要了，他知道什么要什么不要！
鉆研精神：一個系統涉及的領域方方面面，從上層業務到底層實現，會遇到很多很多未知，需要潛心研究。
這可能有點虛，特別是架構思維，只有接觸過很多很多的 Case，才能有些體悟。所以一般來說一個剛畢業的應屆生是很難做好性能測試的。
舉個例子：一般來說呢，會有很多的 micro Benchmark，比如測試網絡 PPS、網絡帶寬等等，那這些對用戶的實際影響是什么呢？很自然地想到，把用戶的 Case 搬過來，這么簡單的一句話，實際很難：用戶的 Case 為什么要這么設計？每個 Case 背后是有業務架構師做了設計的。
用戶的 Case 該怎么測試？客戶實際是怎么壓測的？服務器的壓力應該定在哪里？那請問一個從沒有從事過實際業務需求的人怎么知道這個是合理的？如果有這么一幫人在設計用戶的 Case 性能測試是不是很搞笑。所以如果要做真實的案例性能測試，必須是有一線作戰經驗的同學，他知道怎么樣的壓力是最合適的，他知道這個服務器性能是否夠，是不是要提升。
總結
綜上，性能測試沒那么簡單，性能測試不單單是一個測試，他的要求遠遠高于一名測試人員，他是一名性能架構師，更是一名全能手！
最后，請記住一個好的性能工程師是喂出來的，他要經歷千錘百煉，方有銳劍出鞘！共勉。
原文鏈接：https://developer.aliyun.com/article/784338?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的性能测试真如你想象的那么简单？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 从业务在线到互联互通，钉钉宜搭进入低代码
- 下一篇： Openstack迁移DDH最佳实践