記一次性能測試的經歷

• 2019 年 11 月 10 日
• 筆記

近些天由於多接觸了些性能業務方面，所以一直在忙項目和加班中，不知不覺中進入了996狀態，以至於這兩天才得空寫寫總結。還是希望工作節奏不要這麼緊張，畢竟對人的身心都不是件好事。

工作這麼多年，一直專註於自動化和工具研發，對性能方面做的相對少很多。主要還是沒有實際的上手機會，沒有需求就不能很好的實踐，光看幾本理論知識的書還是不夠的。今天主要就來說說這幾次性能測試所經歷的「坑」。

坑一：測試業務機器準備

首先要說的就是，如果你所在的公司並沒有專職的性能測試人員負責性能測試，那麼100%的可能情況是：沒有性能測試的業務機器。因為沒有人會單獨留出一部分與線上配置一樣的機器空閑在哪裡。

另以一方面因為性能測試與自動化測試不同，不是隨便搞兩台機器能跑起來就行。性能測試為了能準確的評估出線上環境實際的性能表現，測試環境的機器配置需要與線上保持一致，否則壓測出的結果很難拿來作為參考依據。

所以這裡就可能出現第一個坑：沒有符合要求的機器用來搭建性能測試環境。現實情況的就是：臨時各種申請和調配，光機器到位就要至少1周時間。

對於那些有專職性能測試工程師的部門和公司，這種情況就會很少見了。

坑二：性能測試環境搭建

即便你等了一個禮拜把機器等來了，那又怎樣？還有環境要等着你來搭建呢。再說說現在的微服務「橫行」的年代，搭一個服務容易，搭一群你不熟悉的業務環境也就變成「坑」了。而偏偏遇到的性能需求是全鏈路的性能節點都要關注！

當然了，這裡的全鏈路是指測試環境的全鏈路，並不是你所想像的阿里們的線上環境全鏈路。畢竟實現他們那種全鏈路也是要基礎架構提供支持的，不是每個公司都會支持到這種程度。

如果你比較幸運，對於要做性能測試的業務比較熟悉，那麼環境可能自己就能搞定。現實情況卻是：讓開發幫忙搭了一天，才算把部分環境調通，暫時可以進行階段性的性能測試。

可以這麼說：搭環境是性能測試里，最不想做的事情，沒有之一！

坑三：性能測試環境配置

好不容易把環境搭建起來，跑了一波性能測試數據，檢查的時候卻發現「數據量」對不齊。發了300w的量卻只消費了100w，剛開始還以為程序有問題，再後來還以為kafka有積壓，最後才知道是kafka配置跟線上不一致。

所以這裡要長個「心眼」，除了機器配置、軟件配置跟線上一致，基礎服務的資源和配置也要跟線上保持一致，否則很有可能出現一些「意想不到」的狀況。

當然了，這個「坑」是專屬於性能新手的，老手基本上都被坑過千萬遍了，很難在入「坑」。

坑四：性能測試數據準備

還是回到「故事」的源頭，如果你身在一個性能測試較為成熟的公司，那麼數據準備可能不是什麼事情。比如：準確的峰值數據、真實的請求比例以及真實的請求數據。都可能很容易的評估和獲取到。

否則，你可能需要費點勁來評估數據和生產數據。評估基本靠猜，數據基本靠造。壓測完了數據到時有，只是到底準不準，只有上天知道。

不過話說回來，評估這種事情如果沒有歷史數據作為參考，也就只能猜了。不然你以為所謂的「人工智能」是怎麼算出來的。只是有些數據如果能方便的從線上拉去日誌，這個「坑」就可以填上一大半了。

坑五：性能測試壓測平台

這個「坑」本來不想入，但是卻沒有別的辦法。因為這個基礎平台不用的話，也沒有資源去跑壓測服務，也沒有好的辦法發去收集系統資源信息。只能說基礎壓測能力是有了，但是離全流程的性能支持還差那麼一半。

簡單列一下平台的幾個「坑點」：

•不能單個請求調試•沒有檢查點支持•需要執行一段時間才能出結果•不能看日誌，即使有錯誤也看不到

大廠的話這些基礎平台的能力應該要稍微健全點，小店的話自己有權限胡亂造，只有「中不溜」的才有這種情況。

坑六：性能測試資源監控

資源監控在性能測試中也算是比較重要的，但是由於性能平台的限制，只能關聯監控一台服務器，不能滿足多個服務同時監控的需求。

還好可以從運維平台單獨打開多個頁面來查看，只不過後期整理的時候，你想要的圖得一個個自己慢慢整理。所以這個「坑」還好，不算太大。

坑七：性能測試瓶頸分析

性能瓶頸分析是最讓大家津津樂道的，畢竟還是有很多「神學」在裏面。剛學習性能的時候，告訴你的各種套路，當你在實踐時發現一個都用不少。因為你會發現沒有性能瓶頸，至少是沒有明顯的性能瓶頸。

最常見的情況可能不是一上壓力，CPU、內存、磁盤就狂狂飆升；而是換成了「風平浪靜」的場景，最多稍微有點「小高潮」就到頂了。新手遇到這種情況一般都是懵逼的，尤其是你還可能拿不到各種日誌、各種資源監控的情況。

具體的性能分析方法，等攢夠了經驗系統化後，再出個性能分析的系列篇。這裡先說說我遇到的性能瓶頸的「坑」。

•mysql慢查詢。最大的坑，沒有之一•日誌輸出太多。debug的鍋•中間件。都是共用基礎服務惹的禍•帶寬。超大body體的請求需要注意•壓力上不去。生產端還能再快點么

坑八：線上實際效果分析

壓測的時候以預估的量，結果預估的量太大了，導致沒有足夠的壓測機器，只能等比例壓測機器。本來還擔心等比增加後會，線上全量性能效果會不會打折扣，結果讓人大跌眼鏡的是線上實際量遠小於預估量。

當然，說實話也怪不了別人，頭一次做大促難免有點拿捏不住。畢竟即沒有歷史數據參考，也沒有很好的用戶行為模型分析。說壓多少量就壓多少量，其它的咋也不敢說，咋也不敢問。

總結

多做幾次性能項目後，你就會發現性能和功能都是一樣的套路 — 熟練工種。那些坑都填過後，以後再走就是平道了。性能分析也沒有那麼神乎其神的，那些一眼就能看出毛病的人基本都是被坑的多了才長的心眼。

要增強性能分析能力，還要具備很好的系統基礎知識、對業務的熟悉、對架構的理解，另外還有必不可少的實（入）踐（坑）經驗。如果脫離了這些，光拿幾個曲線圖就能給你分析出個所以然來的，不是神棍就是騙子。

80%的時間用在前期環境和數據準備上面，壓測就用一小會，性能瓶頸的分析佔用後面的20%的時間。這個比例在我這來看一點都不誇張。