在生活中，做任何事情之前，最好先確定乙個目標。
同樣的，在我們日常做效能測試之前，最好把本次預期效能指標確定下來，沒有預期指標的衡量，將無法評估測試結果資料是否滿足預期。比如以下這樣的指標：
介面預期tps
查詢介面
入庫介面
在實際工作中呢，最理想的情況是，開發/產品/專案經理已經提前確定好了效能指標，然後把指標明確的告訴你。
但是理想很豐滿，現實很骨感，根據我多年的效能測試經驗來看，大多數提效能需求的人，大多是不太懂效能的，所以根本不會有指標的，或者雖然有指標，但是是拍腦袋決定的，沒有任何依據。
所以作為乙個測試人員，很有必要去通過一些資料分析，在測試之前就先明確乙個相對科學的指標，這樣測試才會更加有價值。
一般來講，我們將壓測的專案分為兩類，一種是老專案，一種新專案。
先看看老專案，老專案是指專案已經上線了，並且已經執行了一段時間，這時候會產生一些歷史資料，可以通過以下手段對歷史資料進行分析
在一些大廠，或者一些發展比較成熟的公司，大多都有各種各樣的業務監控系統，定期監控各業務模組核心介面的呼叫量、平均耗時等等，一般是以分鐘級別做監控，如下圖
我們可以在系統裡檢視過去一周（或者乙個月）內，介面呼叫量最高的那一天，然後再找到當天中介面呼叫量最高的時間點（分鐘級別），比如說是在12:10呼叫量為10000，那麼我們再換算為每秒呼叫量10000/60=166，因此可以確定這個介面tps只要達到166即可滿足。
有的公司（大多數都是創業型公司）根本沒有上述的業務監控系統，那有沒有辦法去評估預期指標呢。
方法也是有的，那就是通過中介軟體的日誌，每個中介軟體都有訪問日誌。比如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%人身上
二八定律是一種社會準則，符合大多數社會現象的規律。同樣也適用於網際網路領域。
具體來說下怎麼通過二八定律來計算預期指標。
比如某**新增了乙個每日簽到送積分功能，由於還沒有上線，所以沒有簽到的資料。**的註冊使用者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%的時間 * 冗餘係數
看了上面一大堆分析，有的朋友可能又說了，別整這些有的沒的，我們公司的專案就是啥都沒有，三無產品，沒有業務監控、沒有中介軟體日誌，也沒有日活資料，那怎麼評估預期指標。
二八定律與長尾理論在SEO營銷中的應用
隨著seo優化在中國市場的迅速傳播，關於seo營銷的討論也隨之成為業內關注的話題。現今許多企業開始利用seo技術展開網路營銷，也開始對seo營銷進行思考 研究和爭論。而二八定律與長尾理論在seo營銷中的應用就是乙個重點話題。二八定律是一位義大利經濟學家巴萊多發明的，又稱二八法則。根據二八法則，企業8...
Windows PDH庫在效能測試中的應用
相信大家都已經使用過了windows自帶的效能測試工具perfmon。perfmon能夠實時的抓取當前環境的硬體資訊,並直觀的展示出來。但是當你想在程式設計中利用這些資料，perfmon就不是那麼方便了。那麼windows是否提供了合適的api來完成這些功能呢？答案是肯定的，這就是performan...
OO課下討論 bug中的「二八定律」
本文主要為討論2020 3 17下午oo課討論的第三個思考題設立 有乙個經典的經驗性原則，叫帕累託原則，也稱為二八定律。這個原則在經濟 社會和科技等多個領域都有精彩的應用和解釋。在 質量方面也有這樣的觀察 80 的bug集中在20 的模組中，針對這個現象，請思考 二八定律又名80 20定律 帕累託法...