1. 程式人生 > >二八定律在性能測試中的應用

二八定律在性能測試中的應用

分鐘 意大利 系統性能 歷史 inf 保險 理想 來看 我們

在生活中,做任何事情之前,最好先確定一個目標。

技術分享圖片

同樣的,在我們日常做性能測試之前,最好把本次預期性能指標確定下來,沒有預期指標的衡量,將無法評估測試結果數據是否滿足預期。比如以下這樣的指標:

接口

預期TPS

查詢接口

1000

入庫接口

2000

在實際工作中呢,最理想的情況是,開發/產品/項目經理已經提前確定好了性能指標,然後把指標明確的告訴你。

技術分享圖片

但是理想很豐滿,現實很骨感,根據我多年的性能測試經驗來看,大多數提性能需求的人,大多是不太懂性能的,所以根本不會有指標的,或者雖然有指標,但是是拍腦袋決定的,沒有任何依據。

所以作為一個測試人員,很有必要去通過一些數據分析,在測試之前就先明確一個相對科學的指標,這樣測試才會更加有價值。

一般來講,我們將壓測的項目分為兩類,一種是老項目,一種新項目。

先看看老項目,老項目是指項目已經上線了,並且已經運行了一段時間,這時候會產生一些歷史數據,可以通過以下手段對歷史數據進行分析

1、業務監控系統

在一些大廠,或者一些發展比較成熟的公司,大多都有各種各樣的業務監控系統,定期監控各業務模塊核心接口的調用量、平均耗時等等,一般是以分鐘級別做監控,如下圖

技術分享圖片

我們可以在系統裏查看過去一周(或者一個月)內,接口調用量最高的那一天,然後再找到當天中接口調用量最高的時間點(分鐘級別),比如說是在12:10調用量為10000,那麽我們再換算為每秒調用量10000/60=166,因此可以確定這個接口tps只要達到166即可滿足。

2、日誌

有的公司(大多數都是創業型公司)根本沒有上述的業務監控系統,那有沒有辦法去評估預期指標呢。

方法也是有的,那就是通過中間件的日誌,每個中間件都有訪問日誌。比如Nginx的access.log,該日誌中詳細記錄了每個HTTP請求的訪問時間、url、響應狀態碼、響應時間等,如下圖

技術分享圖片

有了這些數據就好說了,我們可以通過一些腳本(自己編寫或者找運維幫忙),統計出每個接口在哪個時間段調用最高,調用量峰值是多少。根據峰值數據,最終可以計算出每秒的調用量,然後可以將這個指標定為接口的預期TPS。

接下來我們重點說一下新項目,也是在實際工作中遇到最多的情況。

新項目是還沒有上線,在上線前希望先進行一輪壓測,評估項目性能是否能支撐當前的用戶,這個時候性能預期指標更為重要。但是由於是新項目,線上並沒有任何的歷史監控數據和日誌數據,所以之前介紹的方法就不再適用,這個時候需要使用另外一種方法來評估性能指標,那就是“二八定律”。

什麽是二八定律?先來看一下定義:

二八定律又名80/20定律、帕累托法則(Pareto‘s principle)也叫巴萊特定律、朱倫法則(Juran‘s Principle)、關鍵少數法則(Vital FeRule)、不重要多數法則(Trivial Many Rule)最省力的法則、不平衡原則等,被廣泛應用於社會學及企業管理學等。

二八定律是19世紀末20世紀初意大利經濟學家帕累托發現的。他認為,在任何一種事物中,最重要的只占其中一小部分,約20%,其余80%盡管是多數,卻是次要的。

從經濟學上看,世界上80%的財富,都集中的20%的人手裏

技術分享圖片

從心理學來說,人類80%的智慧,都集中在20%人身上

技術分享圖片

技術分享圖片

二八定律是一種社會準則,符合大多數社會現象的規律。同樣也適用於互聯網領域。

一個網站有成千上萬的用戶,但是80%的用戶請求是發生在20%的時間內,比如大家去網上購物,基本也都集中在中午休息或晚上下班後。二八定律的核心原則是關註重要部分,忽略次要部分。系統性能如果能支撐發生在20%時間內的高並發請求,必然也能支持非高峰期的訪問。

具體來說下怎麽通過二八定律來計算預期指標。

首先先預估系統的每日總請求數,這個沒有固定的方法,如果沒有任何歷史數據參考,一般是通過用戶量或者其他關聯系統來評估。

比如某網站新增了一個每日簽到送積分功能,由於還沒有上線,所以沒有簽到的數據。網站的註冊用戶1000w,日活躍用戶大概是100w左右,那麽最極端情況下,這100w人都會來簽到(實際肯定不會這麽多人來簽到,但是評估指標要盡量往高評,以免出現極端情況),那麽每天大概有100w次簽到請求,80%的請求數就是100w*0.8=80w。

其次確定系統的20%時間,大多數系統是24小時對外提供服務的(也有一些系統,比如政府類的項目,是在一天的某個時間段提供服務的)。但是大多數系統在0點-6點之間訪問量很少,從一天的總訪問量來看,可以忽略不計。所以統計時間的時候,可以把這段時間去掉,一天24小時去掉這6個小時,還剩下18個小時,那20%的時間=18小時*3600秒*0.2=12960秒。

最終計算出來的結果為80w請求/12960秒=61左右。也就是說接口TPS滿足61即可。

但是也需要考慮一個問題,因為上面的用戶請求是按照100w評估,也有可能推出這個活動後,每日會有超過100w的用戶來簽到。簽到業務每個用戶只能執行一次,如果是其他業務,可能會有多次操作。所以評估出來指標後,為了更加保險一些,最好再乘以一個冗余系數,提高預期指標,防止人為評估造成預期指標偏低的情況。

這個冗余系數一般定為2-5之間(個人經驗),上面計算出來的tps指標為61,如果再乘以一個冗余系數3,那麽最終tps指標就定為183。同時,將來項目上線後,可以通過對項目接口的峰值監控,來對比之前評估的算法結果,調整冗余系數,最終隨著不斷的數據積累,將會形成一套本項目的性能模型。

那麽將來項目上線後,接口的訪問量真的和計算的一模一樣嗎?這個肯定不會,大家一定得知道一個原則,性能測試從來都不是一門非常精確的技術。二八定律也並不是100%適用於所有業務場景。在沒有任何歷史數據參考的背景下,二八定律相對來說是一種相對來說靠譜的算法,最起碼有一定的理論依據,比拍腦袋猜的值靠譜多了。

總結一下,二八定律的算法為 80%的請求 / 20%的時間 * 冗余系數

看了上面一大堆分析,有的朋友可能又說了,別整這些有的沒的,我們公司的項目就是啥都沒有,三無產品,沒有業務監控、沒有中間件日誌,也沒有日活數據,那怎麽評估預期指標。

對於這樣的系統和公司,我的建議是,可以不要管什麽指標了,直接開始測試,測試完成後,把本次測試數據發送給相關人員,然後大家召開會議會結果進行討論,最終由領導來拍板決定系統性能是否滿足需求。

技術分享圖片

二八定律在性能測試中的應用