性能分析

不合標準的應用程序性能會產(chǎn)生軟件或網(wǎng)絡問題。為確保軟件滿足或超過設計的期望值，有必要分析應用程序的性能以發(fā)現(xiàn)潛在的問題。這個過程被稱為“性能分析”。它包括檢查應用程序以確保每個組件有效地工作，并根據(jù)設計密切注視處理器的使用、網(wǎng)絡和系統(tǒng)服務、存儲和輸入/輸出(I/O)。

響應時間的2/5/8原則

• 2秒鐘之內(nèi)響應用戶是非常好的。

• 2-5秒鐘之內(nèi)響應用戶是可以接受的。

• 5-8秒鐘是用戶能接受的響應的上限。

• >8秒鐘是比較糟糕的，用戶會選擇離開這個Web站點或發(fā)起第二次請求。

Bug分布的2/8原則

80%的bug分布在20%的模塊里

業(yè)務分布的2/8原則

80%的業(yè)務量在20%的時間里完成

如何理解，下面我們來個例子吧

用戶登錄場景：早高峰時段，8：50---9：10，5000坐席上線登陸。

•     業(yè)務量：5000個 

•     時間：20x60=1200秒

•     吞吐量=80%x業(yè)務量/(20%*時間)=4000/240=16.7/秒

而并非5000/1200=4.1/秒

實際上，登錄請求數(shù)分布是一個正態(tài)分布，最高峰時肯定比4.1/秒更高，高峰段實際上完成了80%的業(yè)務量，卻只花了20%的時間。

溫馨提示：

1. 二八原則計算的結(jié)果并非在線并發(fā)用戶數(shù)，是系統(tǒng)要達到的處理能力（吞吐量），初學者容易被誤導，那這這個數(shù)據(jù)就去設置并發(fā)數(shù)，這是錯誤滴。

2. 如果你的系統(tǒng)性能要求更高，也可以選擇一九原則或更嚴格的算法，二八原則比較通用，一般系統(tǒng)性能比較接近這個算法而已，大家應該活用。

理發(fā)店模型

模型假設

在這個理發(fā)店中，事先做如下的假設：

1. 理發(fā)店共有3名理發(fā)師

2. 每位理發(fā)師剪一個頭發(fā)的時間都是1小時

3. 顧客們對于每次光顧理發(fā)店時所能容忍的等待時間+剪發(fā)時間是3小時，而且等待時間越長，顧客的滿意度越低。如果3個小時還不能剪完頭發(fā)，我們的顧客會立馬生氣的走人

場景構(gòu)建

場景1

理發(fā)店內(nèi)只有1位顧客 

有1名理發(fā)師為他提供服務，另外2位等著或打雜幫忙。1小時后，兩位顧客剪完頭發(fā)出門 在這1個小時里，整個理發(fā)店只服務了1位顧客，這位顧客花費在這次剪發(fā)的時間是1小時。

理發(fā)店內(nèi)同時有2位顧客

同時有2名理發(fā)師在為顧客服務，另外1位等著或打雜幫忙。1小時后，兩位顧客剪完頭發(fā)出門 在這1小時里，整個理發(fā)店服務了兩位顧客，這兩位顧客花費在剪發(fā)的時間均為1小時

理發(fā)店內(nèi)同時有3位顧客

同時有3名理發(fā)師在為顧客服務。1小時后，三位顧客剪完頭發(fā)出門

在這1小時里，整個理發(fā)店服務了三位顧客，這三位顧客花費在剪發(fā)的時間均為1小時

場景總結(jié)：
在理發(fā)店同時服務的顧客數(shù)量從1位增加到3位的過程中，隨著顧客數(shù)量的增多，理發(fā)店的整體工作效率在提高，而且每位顧客在理發(fā)店內(nèi)所呆的時間并未延長。

當然，可以假設當只有1位顧客和2位顧客時，空閑的理發(fā)師可以幫忙打雜，使得其他理發(fā)師的工作效率提高，并使每位顧客的剪發(fā)時間小于1小時 不過即使根據(jù)這個假設，雖然隨著顧客數(shù)量的增多，每位顧客的服務時間有所延長，但是這個時間始終還被控制在顧客可接受的范圍之內(nèi)，并且顧客是不需要等待的。

場景2

隨著理發(fā)店的生意越來越好，顧客也越來越多，出現(xiàn)新的場景

假設有一次顧客A、B、C剛進理發(fā)店準備剪發(fā)，外面一推門又進來了顧客D、E、F

因為A、B、C三位顧客先到，所以D、E、F三位只好坐在長板凳上等著

1小時后，A、B、C三位剪完頭發(fā)走了，他們每個人這次剪發(fā)所花費的時間均為1小時?？墒荄、E、F三位就沒有這么好運，因為他們要先等A、B、C三位剪完才能剪，所以他們每個人這次剪發(fā)所花費的時間均為2小時——包括等待1小時和剪發(fā)1小時。

通過上面這個場景我們可以發(fā)現(xiàn)，對于理發(fā)店來說，都是每小時服務三位顧客——第1個小時是A、B、C，第二個小時是D、E、F；但是對于顧客D、E、F來說，“響應時間”延長了。

場景3

假設這次理發(fā)店里一次來了9位顧客，這9位顧客中有3位的“響應時間”為1小時，有3位的“響應時間”為2小時（等待1小時+剪發(fā)1小時），還有3位的“響應時間”為3小時（等待2小時+剪發(fā)1小時）——已經(jīng)到達用戶所能忍受的極限。假如在把這個場景中的顧客數(shù)量改為10，那么我們已經(jīng)可以斷定，一定會有1位顧客因為“響應時間”過長而無法忍受，最終離開理發(fā)店走了。（其實這種場景在我們生活中也是非常常見的一種情況）

上面的場景如何與性能測試掛鉤呢？

性能測試曲線模型是一條隨著測試時間不斷變化的曲線，與服務器資源，用戶數(shù)或其他的性能指標密切相關的曲線。

　　一般的性能測試曲線圖主要分為三個區(qū)域，分別是：

• light load（輕壓力區(qū)）

• heavy load（重壓力區(qū)）

• Buckle Zone

　　圖中的三條曲線，分別代表：

• Utilization（資源利用率，指軟硬件資源）

• Throughput（吞吐量，即單位時間內(nèi)處理請求的數(shù)量）

• Response Time（響應時間）

　　圖中坐標軸的橫軸從左到右表示并發(fā)用戶數(shù)（Number of Concurrent Users）的不斷增長。

分析：

　　資源利用率在第一區(qū)域穩(wěn)定增長，在第二區(qū)域小幅增長，在第三區(qū)域呈直線，表示飽和。

　　響應時間隨著并發(fā)用戶數(shù)的增加，在前兩個區(qū)域基本平穩(wěn)，小幅遞增，在第三個區(qū)域急速遞增，產(chǎn)生拐點。

　　同時，吞吐量隨著并發(fā)用戶數(shù)的增加，請求增加，在第一區(qū)域基本穩(wěn)定上升，在第二區(qū)域處理達到頂點，隨后開始下降。

　　當系統(tǒng)的負載等于最佳并發(fā)用戶數(shù)時，整體效率最高，也沒有資源被浪費，用戶也不需要等待；當系統(tǒng)負載處于最佳并發(fā)用戶數(shù)和最大用戶并發(fā)數(shù)之間時，系統(tǒng)可以繼續(xù)工作但用戶的等待時間延長；當系統(tǒng)負載大于最大并發(fā)用戶數(shù)時，用戶滿意度基本為零，甚至放棄訪問。

根據(jù)區(qū)域交界處，又衍生兩個概念：

• 最佳并發(fā)用戶數(shù)

The Optimum Number of Concurrent Users

Light Load和Heavy Load 兩個區(qū)域交界處的并發(fā)用戶數(shù)

• 最大并發(fā)用戶數(shù)

The Maximum Number of Concurrent Users

Heavy Load和Buckle Zone兩個區(qū)域交界處的并發(fā)用戶數(shù)

性能拐點

1、對一個基本的請求做并發(fā)測試，看是否能達到tps=1000，或者找到tps拐點。

2、設置線程數(shù)為1，循環(huán)數(shù)為1，查看Throught為多少（假如是170），計算下如果想要達到1000的話大概需要多少線程數(shù)，1000/170，大約為6。

3、將線程數(shù)設置為6，對請求加一個Throught shaping timer ，設置如下：

 4、將Tracactions per second的顆粒度調(diào)低點（settings）

5、運行，查看tps

性能測試行業(yè)常用的性能指標表示法

響應時間(RT response time)

　　對于單機的沒有并發(fā)操作的應用系統(tǒng)而言，人們普遍認為響應時間是一個合理且準確的性能指標。需要指出的是，響應時間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實際上取決于用戶對該響應時間的接受程度。對于一個游戲軟件來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對于編譯系統(tǒng)來說，完整編譯一個較大規(guī)模軟件的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于用戶來說都是可以接受的。

吞吐量(Throughput)

      吞吐量是指系統(tǒng)在單位時間內(nèi)處理請求的數(shù)量。對于無并發(fā)的應用系統(tǒng)而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數(shù)。前面已經(jīng)說過，對于單用戶的系統(tǒng)，響應時間（或者系統(tǒng)響應時間和應用延遲時間）可以很好地度量系統(tǒng)的性能，但對于并發(fā)系統(tǒng)，通常需要用吞吐量作為性能指標。

　　對于一個多用戶的系統(tǒng)，如果只有一個用戶使用時系統(tǒng)的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由于每個請求的處理過程中有許多不走難以并發(fā)執(zhí)行，這導致在具體的一個時間點，所占資源往往并不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間并不隨用戶數(shù)的增加而線性增加。實際上，不同系統(tǒng)的平均響應時間隨用戶數(shù)增加而增長的速度也不大相同，這也是采用吞吐量來度量并發(fā)系統(tǒng)的性能的主要原因。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數(shù)和用戶使用模式的系統(tǒng)，如果其最大吞吐量基本一致，則可以判斷兩個系統(tǒng)的處理能力基本一致。

并發(fā)用戶數(shù)

　　并發(fā)用戶數(shù)是指系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶的數(shù)量。與吞吐量相比，并發(fā)用戶數(shù)是一個更直觀但也更籠統(tǒng)的性能指標。實際上，并發(fā)用戶數(shù)是一個非常不準確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發(fā)出不同數(shù)量的請求。一網(wǎng)站系統(tǒng)為例，假設用戶只有注冊后才能使用，但注冊用戶并不是每時每刻都在使用該網(wǎng)站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網(wǎng)站時會花很多時間閱讀網(wǎng)站上的信息，因而具體一個時刻只有部分在線用戶同時向系統(tǒng)發(fā)出請求。這樣，對于網(wǎng)站系統(tǒng)我們會有三個關于用戶數(shù)的統(tǒng)計數(shù)字：注冊用戶數(shù)、在線用戶數(shù)和同時發(fā)請求用戶數(shù)。由于注冊用戶可能長時間不登陸網(wǎng)站，使用注冊用戶數(shù)作為性能指標會造成很大的誤差。而在線用戶數(shù)和同事發(fā)請求用戶數(shù)都可以作為性能指標。相比而言，以在線用戶作為性能指標更直觀些，而以同時發(fā)請求用戶數(shù)作為性能指標更準確些。

QPS每秒查詢率(Query Per Second)

　　每秒查詢率QPS是對一個特定的查詢服務器在規(guī)定時間內(nèi)所處理流量多少的衡量標準，在因特網(wǎng)上，作為域名系統(tǒng)服務器的機器的性能經(jīng)常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數(shù)，也即是最大吞吐能力。（看來是類似于TPS，只是應用于特定場景的吞吐量）

TPS每秒執(zhí)行的事務數(shù)量(throughput per second)

      TPS (transaction per second)代表每秒執(zhí)行的事務數(shù)量，可基于測試周期內(nèi)完成的事務數(shù)量計算得出。例如，用戶每分鐘執(zhí)行6個事務，TPS為6 / 60s = 0.10 TPS。同時我們會知道事務的響應時間(或節(jié)拍)，以此例，60秒完成6個事務也同時代表每個事務的響應時間或節(jié)拍為10秒。

估算QPS峰值

原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間。
公式：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時間每秒請求數(shù)(QPS) 。
機器：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器 。

每天300w PV 的在單臺機器上，這臺機器需要多少Q(mào)PS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
故該機器支持139QPS即可。

并發(fā)數(shù)

首先，理解三個用戶數(shù)的概念：

系統(tǒng)用戶數(shù)、在線用戶數(shù)、并發(fā)用戶數(shù)

系統(tǒng)用戶數(shù)就是一個系統(tǒng)中所有的注冊用戶數(shù)。eg. 當前微信中的所有注冊用戶數(shù)；在線用戶數(shù)是當前登錄系統(tǒng)的用戶數(shù)，eg.當前登錄微信的總用戶數(shù) （均為在線狀態(tài)，不管該用戶做什么操作）；并發(fā)用戶數(shù)是指對Server產(chǎn)生壓力的用戶數(shù)，eg.當前微信所有登錄用戶中，正在進行操作的用戶數(shù)（僅指對Server產(chǎn)生壓力的操作）

我們測試時僅關注并發(fā)用戶數(shù)，一般，需求采集人員會將線上的并發(fā)用戶數(shù)根據(jù)日志或工具分析統(tǒng)計出。測試時，要以性能測試需求為準，此外，并發(fā)操作也包含多種情況 ，如所有用戶同時進行購買或支付操作；或多個用戶同時發(fā)出多個不同請求，如加入購物車、刪除商品、增減數(shù)量、支付、退款等操作。

響應時間

先看一個請求從發(fā)出到用戶看到結(jié)果的過程：用戶發(fā)送一個請求后，通過網(wǎng)絡傳輸、DNS解析等步驟到達Server端后，Server通過各種算法處理，將結(jié)果通過網(wǎng)絡傳輸返回到Client，Client要經(jīng)過解析渲染等步驟，最后才呈現(xiàn)給用戶。

通過以上流程可知，響應時間的計算模式：響應時間=請求傳輸時間+Server處理時間+響應傳輸時間+前端解析渲染時間。

由此可見，在工作中，一方面響應時間要根據(jù)不同業(yè)務及用戶的具體要求而定；另一方面分析結(jié)果時要注意當前的業(yè)務模型（如前端性能測試與服務器性能測試）

資源利用率

關于資源利用率初期了解以下幾個重要指標即可：

CPU

對于CPU都不陌生，簡言之，是用來處理＼判斷事務的，CPU一般有系統(tǒng)CPU與用戶CPU，前者是 處理系統(tǒng)占用的資源 ；而后者是處理應用程序占用的資源 。

網(wǎng)絡

即網(wǎng)絡傳輸?shù)牧髁浚瑴y試過程中對網(wǎng)絡的監(jiān)控以，以分析是否存在瓶頸。

IO

即，Input/Output，輸入/輸出。關注與磁盤的交互頻率等

內(nèi)存

即數(shù)據(jù)存儲區(qū)域。一般讀數(shù)據(jù)時從內(nèi)存中讀取要比硬盤讀取快很多 ，但需要關注的是內(nèi)存溢出或內(nèi)存泄漏問題。

隊列

屬于數(shù)據(jù)結(jié)構(gòu)的概念了 ，是一種線性表，可以在隊列前刪除，在隊尾處進行插入。測試過程中，如果發(fā)現(xiàn)隊列越來越長，很可能會發(fā)生阻塞問題。