loadrunner 關於計算及瓶頸識別（五）

         通過吞吐量，併發數和響應時間，我們可以大概瞭解一個系統的效能。當併發數增大時，吞吐量會增大，響應時間有所增加。但併發數繼續增加時，響應時間增大的幅度變大，而吞吐量逐漸平緩穩定。當併發數繼續增大，響應時間會明顯快速增大，而吞吐量可能因為伺服器壓力過大，反而出現下降。所以一定要結合起來一起看。

一、併發使用者數

        在實際的效能測試工作中，測試人員一般比較關心的是業務併發使用者數，也就是從業務角度關注究竟應該設定多少個併發數比較合理，因此，在後面的討論中，也是主要針對業務併發使用者數進行討論，而且，為了方便，直接將業務併發使用者數稱為併發使用者數。當然，在效能測試上，任何公式都不是嚴謹的，最重要的是對系統做出有效正確的分析

        併發使用者數量的統計的方法目前還沒有準確的公式，因為不同系統會有不同的併發特點。例如OA系統統計併發使用者數量的經驗公式為：使用系統使用者數量*(5%~20%)。對於這個公式是沒有必要拘泥於計算的結果，因為為了保證系統的擴充套件空間，測試時的併發使用者數量要稍微大一些，除非是要測試系統能承載的最大併發使用者數量。舉例說明：如果一個OA系統的期望使用者為1000個，只要測試出系統能支援200個併發使用者就可以了。

1、經典公式

（1）  平均的併發使用者數： C = nL/T      

                其中C是平均的併發使用者數，n是平均每天訪問使用者數，L是一天內使用者從登入到退出的平均時間（操作平均時間），T是考察時間長度（一天內多長時間有使用者使用系統）

            （ps: n的單位為day, L和T的單位為h）

（2）併發使用者數峰值 C‘ = C + 3*根號C

            舉例1.  假設系統A，該系統有3000個使用者，平均每天大概有400個使用者要訪問該系統（可以從系統日誌從獲得），對於一個典型使用者來說，一天之內使用者從登陸到退出的平均時間為4小時，而在一天之內，使用者只有在8小時之內會使用該系統。

           →  C = nL/T =  400*4 / 8 = 200

           →  C‘ =  C + 3*根號C = 200 + 3* 根號200 = 243

             舉例2. 某公司為其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬資訊，但並不是每個人都會用這個系統，假設只有50%的人會定期用該系統，這些人裡面有70%是在每個月的最後一週使用一次該系統，且平均使用系統時間為5分鐘。 則一個月最後一週的平均併發使用者數為（朝九晚五）：

           → C = nL/T  = （170000 * 50% *70% / 5） *（5/60）/  8 = 124

              舉例3 .早上8點上班，7點半到8點的30分鐘的時間裡使用者會登入簽到系統進行簽到。公司員工為1000人，平均每個員上登入簽到系統的時長為5分鐘。可以用下面的方法計算。

            → C = nL/T  =  1000*(5/60)/0.5 = 166.7

2、通用公式（對絕大多數場景）

            （1）  平均的併發使用者數 =  （使用者總量/統計時間）*影響因子                     （一般為3，可以根據實際情況增大）

              舉例4 .每天電梯乘坐人數為5萬人次，每天早高峰是7到9點，晚高峰是6到7點，根據8/2原則，80%的乘客會在高峰期間乘坐地鐵，

                            則每秒到達地鐵檢票口的人數為50000*80%/（3*60*60）=3.7，約4人/S

                            考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要大，

                            假定每個人需要3秒才能進站，那實際併發應為4人/s*3s=12

3、根據PV估算

                  （1）  平均的併發使用者數 = （PV/統計時間）*影響因子  --------和上面類似

                        舉例5.  比如一個網站，每天的PV（頁面瀏覽數page views）大概1000w，根據2/8原則，我們可以認為這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那麼TPS(每秒處理的訊息數 Transaction Per Second )為：

                          TPS =  1000w*80%/(9*3600)=246.92個/s,取經驗因子3，則併發量應為：

                           C =  246.92*3=740

4、根據TPS估計

         C = (Think time + 1)*TPS

5、根據系統使用者數計算

           C = 系統最大線上使用者數的8%到12% , 舉例1：C  = 3000*0.08 = 240  (與公式相差40)

備註：本人目前在網上只找到了這5種，計算併發使用者數的方法，其他計算方法，歡迎大家留言補充

二、吞吐量

吞吐量計算為：F = Vu * R / T    （個/s）

F為事務吞吐量，Vu為虛擬使用者數個數，R為每個虛擬使用者發出的請求數，T為處理這些請求所花費的時間

三、響應時間

對請求作出響應所需要的時間

四、舉例 :  效能測試流程

制定效能測試目標-->選擇效能測試工具-->設計效能測試-->執行效能測試指令碼-->監控分析系統-->效能調優

1、目標：

如，系統需滿足系統使用者數220w（目標使用使用者/註冊使用者）、線上使用者50w, 併發使用者1w（在同一時刻與伺服器進行了互動的線上使用者數量）的情況下，發帖響應時間不超過2秒，系統資源使用率不超過30%。

經典公式：C = nL/T  =  50w* (5/60) / 8 =  0.52w

根據系統使用者數計算： = 50 w* 8% =  4   -_-||

2、選擇效能測試工具：

可選擇LR、Locust、jmeter等主流測試工具，這篇文章主要介紹LR相關。

3、效能測試準備：

測試指令碼開發、負載的生成規則及監控方式、測試環境的搭建。

4、負載過程、負載後對資料進行分析，這個分析需要眾多專家共同協作，找出資料背後的問題，確定效能瓶頸。

5、確定瓶頸後，進行軟硬體調優，調優完成重複之前的步驟。

        需要與資料庫互動的壓測，事務pass不代表實際操作一定成功，首先確保指令碼中的檢查點要寫正確，其次務必查詢一下資料庫是否有相應操作。

        場景測試的前10分鐘，隨時關注一下TPS、響應時間，若TPS過低或響應時間太慢，當機立斷停止場景執行，找一下執行慢的原因，若不是指令碼設定原因，找一下開發同學反饋問題，待開發調優後再壓測，避免浪費時間。

        若無以上問題，場景測試的前1小時，關注一下曲線波動情況，若有明顯下降或上下波動很明顯，請聯絡開發同學查原因。

        若1小時已通過，可以連續跑穩定性測試，12小時或更長，當然中間有時間也要關注一下曲線圖是否有異常。

五、LR如何識別系統瓶頸

1、Average Transaciton Response Time（事務平均響應時間）

        通過它可以分析場景執行期間應用系統的效能走向。隨著測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨著投產時間的變化，整體效能將會有下降的趨勢。

2、Hits per Second（每秒點選次數）

        是Vuser每秒向web伺服器提交的HTTP請求數，檢視曲線情況可以判斷被測系統是否穩定。曲線呈下降趨勢表明web伺服器的響應速度在變慢，其原因可能是伺服器瓶頸問題，也有可能是Vuser數量減少，訪問伺服器的HTTP請求減少。

3、Transactions per Second（每秒通過事務數）

        當壓力加大時，TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是伺服器開始出現瓶頸。

4、吞吐量（Throughput） 

            表示伺服器在任意時間的吞吐能力，即任意時間伺服器傳送給Vusers的流量。其是度量伺服器效能的重要指標，度量單位是位元組，另外也有兆位元組。 

5、執行Vuser—吞吐量合併關聯圖

併發使用者數和吞吐量瓶頸之間存在一定的關聯，（在網路和伺服器正常的情況下，隨著併發使用者數增加，網路吞吐量也會增加。）因此可以通過不斷的增加併發使用者書和吞吐量觀察系統的效能瓶頸。然後從網路、資料庫、應用伺服器和程式碼本身4個環節確定系統的效能瓶頸。

6、檢視事務是否全部通過    

        如果有事務失敗，則需要深入分析原因。很多時候，事務不能正常執行意味著系統出現了瓶頸，如果事務失敗過多，則應該降低壓力繼續進行測試

7、執行Vuser—平均事務響應時間合併關聯圖

        通過該合併圖可以分析隨著使用者數量的變化，各個事務平均響應時間的變化，從而可以得出各個事物在制定時間內最大的併發使用者數。

8、Hits per Second—Throughput 合併關聯圖

        在比較吞吐量和每秒的點選率中我們可以獲得伺服器在執行過程中的情況。如果伺服器如和預期的一樣在執行，那麼吞吐量會隨著它每秒的點選量增加而增加。這是期望實現的情況，因為點選增加一次就會需要伺服器傳送更多的資訊給使用者。如果電機的次數增加而吞吐量恆定或減少以及在固定範圍內壁咚，就說明伺服器無法執行增加的請求（每秒點選率），結果就是事務反應時間的增加。

9、HTTP  Responses per Second（每秒HTTP響應數）

        “每秒HTTP響應數”是顯示執行場景過程中每秒從Web伺服器返回的不同HTTP狀態碼的數量，還能返回各類狀態碼的資訊，可以判斷伺服器在壓力下的執行情況，也可以通過對圖中顯示的結果進行分組，進而定位生成錯誤的程式碼指令碼。常見http狀態返回程式碼如下：

200（成功）伺服器已成功處理了請求。通常，這表示伺服器提供了請求的網頁。

201（以建立）請求成功，並且伺服器建立了新的資源。

202（已接受）伺服器已接受請求，但尚未處理。

203（非授權資訊）伺服器已成功處理了請求，但返回的資訊可能來自另一來源。

204（無內容）伺服器已成功處理了請求，但沒有返回任何內容。

205（重置內容）伺服器已成功處理了請求，但沒有返回任何內容。要求使用者清除表單內容，輸入新的內容

206（部分內容）伺服器成功處理了部分請求。

301（永久重定向）請求的網頁已永久移動到新位置。伺服器返回此響應（對Get或Head請求的響應）時。會自動將請求者轉到新位置。

404（請求的網頁未找到）伺服器找不到請求的網頁。例如，對於伺服器尚不存在的網頁經常會返回此程式碼.

500（伺服器內部錯誤）伺服器遇到錯誤，無法完成請求，一般是由於頁面程式碼載入出錯造成。