|—1、性能測試簡介

指通過自動化的測試工具]模擬多種正常、[峰值]以及[異常負載條件來對系統的各項性能指標進行測試

|—1.1、對性能的認識

從用戶的角度：

從開發的角度：

從系統管理員的角度：

那么？測試應該關注哪些呢？

測試人員通常是做為軟件質量控制的一個角色，不僅僅是找bug，需要對整個軟件的質量負責，性能也屬于質量的一部分，因此測試人員眼中的性能應該是全面的，考慮的東西也需要全面：

? - 測試人員需要考慮全面的性能，包括[用戶、開發、管理員]等各個視角的性能。

? - 測試人員在做性能測試時除開要關注表面的現象如[響應時間]，也需要關注本質，比如用戶看不到的[服務器資料利用率]，架構設計是否合理？代碼是否合理等方方面面。

|—2、目的

? - 1. 系統的穩定/可靠運營---長時間、高負載測試下交易成功率、資源穩定性。

? - 2. 成本的優化配置--最優CPU數量、內存數量、服務器數量、專線帶寬

? - 3. 給用戶帶來更好的體驗，運行速度快（平均響應時間），流暢（占用我們的硬件資源少）

? - 4. 判斷目前系統的性能瓶頸，一到關鍵時候比較卡，一般是人多的時候比較卡（并發）

? - 5. 系統應用能夠適應未來的業務增長

|—3、性能測試工具

? - 1. JMeter

? - 2. LR(LoadRunner)

? - 3. postman

? - 4. SoupUI

|—4、性能測試的分類

? - 1. 并發測試

? - 2. 壓力測試（強度測試)

? - 3. 疲勞測試

? - 4. 負載測試

? - 5. 配置測試

? - 6. 可靠性測試

|—4.1、并發測試

并發測試就是模擬一群人同一時間做事并發測試就是對被測系統的并發處理能力進行考察的一種測試手段（可以是某個功能模塊或數據記錄）一般都是看在絕對并發的情況下，系統能承載多大的并發量，是否存在死鎖或其者他性能問題。或者在一定的并發量下，系統的響應時間是否是可接受的。

特點：

- 1、這種性能測試方法主要關注系統可能存在的并發問題，例如系統中的內存泄漏、線程鎖和資源爭用方面的問題。

- 2、這種性能測試方法可以在開發的各個階段使用需要相關的測試工具的配合和支持。也就是說，這種測試關注點是多個用戶同時（并發）對一個模塊或操作進行加壓。

- 1、絕對并發：

一種是嚴格意義上的并發，即所有的用戶在同一時刻做同一件事或操作，這種操作一般指做同一類型的業務。比如，所有用戶同一時刻做并發登陸，同一時刻做表單提交。

比如：12306春運期間的放票，一到放票開始，N多的用戶在同一時間點對服務器發起買票的請求。比如8:00放票時段，有100萬用戶對12306發起了買票的請求。

- 2、非絕對并發：

另外一種并發是廣義范圍的并發，這種并發與前一種并發的區別是，盡管多個用戶對系統發出了請求或者進行了操作，但是這些請求或都操作可以是相同的，也可以是不同的。比如，在同一時刻有用戶在登錄，有用戶在提交表單。在一定的并發量下，***系統的響應時間是否是可接受的

|—4.2、壓力測試

壓力測試是在接近用戶承載量極限以下一些（還不足以把系統壓垮的用戶量），較長時間不間斷執行的性能測試，是檢查系統穩定性，系統性能瓶頸的一種常用場景。

壓測時間，一般場景都運行10-15分鐘。如果是疲勞測試，可以壓一天或一周，根據實際情況來定。

壓力測試分兩種場景：

- 一種是單場景，壓一個接口的

- 第二種是混合場景，多個有關聯的接口。

|—4.3、疲勞測試

疲勞測試是采用系統穩定運行情況下能夠支持的最大[并發用戶數]，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程。

一般情況下以服務器能夠正常穩定響應請求的最大[并發用戶數]進行一定時間的疲勞測試，獲取交易執行指標數據和監控數據。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低用戶數、縮短測試周期等。還有一種情況的疲勞測試是對當前系統性能的評估，用系統正常業務情況下[并發用戶數]為基礎，進行一定時間的疲勞測試。

|—4.4、負載測試

就是一批一批的加用戶，待到當前在線用戶執行穩定后，再加下一批的用戶，像這樣不停的持續加壓，直至系統性能明顯下降或系統崩潰為止。是測試系統用戶上限，查找系統性能瓶頸的重要手段。通常在還不知道系統能承載多大業務量的情況下，為找到用戶承載量極限或為了快速定位系統性能瓶頸時，會采用此種方式進行測試。

特點：

- 1、這種性能測試方法的主要目的是找到系統處理能力的極限。

- 2、這種性能測試方法需要在給定的測試環境下進行，通常也需要考慮被測試系統的業務壓力量和典型場景、使得測試結果具有業務上的意義。

- 3、這種性能測試方法一般用來了解系統的性能容量，或是配合性能調優來使用。

|—4.5、配置測試

配置測試方法通過對被測系統的軟\硬件環境的調整，了解各種不同對系統的性能影響的程度，從而找到系統各項資源的最優分配原則。

也就是說，這種測試關注點是“微調”，通過對軟硬件的不段調整，找出這他們的最佳狀態，使系統達到一個最強的狀態。

特點：

- 1、這種性能測試方法的主要目的是了解各種不同因素對系統性能影響的程度，從而判斷出最值得進行的調優操作。

- 2、這種性能測試方法一般在對系統性能狀況有初步了解后進行。

- 3、這種性能測試方法一般用于性能調優和規劃能力。

|—4.6、可靠性測試

在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。

也就是說，這種測試的關注點是“穩定”，不需要給系統太大的壓力，只要系統能夠長期處于一個穩定的狀態。

特點：

- 1、這種性能測試方法的主要目的是驗證是否支持長期穩定的運行。

- 2、這種性能測試方法需要在壓力下持續一段時間的運行。（2~3天）

- 3、測試過程中需要關注系統的運行狀況。

備注：一般企業中作得比價多是并發測試，壓力測試，根據具體需求場景，有必要的話也會適當的作一些負載測試，疲勞測試。

和負載測試的概念比較接近的是壓力測試。通俗地講，壓力測試是為了發現在多大并發壓力下系統的性能會變得不可接受，或者出現性能拐點（崩潰）的情況。在加壓策略上，壓力測試會對被測系統逐步加壓，在加壓的過程中考察系統性能指標的走勢情況，最終找出系統在出現性能拐點時的并發用戶數，也就是系統支持的最大并發用戶數。

最后再說下疲勞強度測試。其實疲勞強度測試的加壓策略跟負載測試也很接近，都是對系統模擬出系統能承受的最大業務負載量，差異在于，疲勞強度測試更關注系統在長時間運行情況下系統性能指標的變化情況，例如，系統在運行一段時間后，是否會出現事務處理失敗、響應時間增長、業務吞吐量降低、CPU/內存資源增長等問題。

|—5、性能測試指標

從維度上劃分，性能指標主要分為兩大類，分別是業務性能指標和系統資源性能指標。

|—5.1、業務性能指標可以直觀地反映被測系統的實際性能狀況，常用的指標項有：

? 　1.并發用戶數

? 　2.事務吞吐率（TPS/RPS）

? 　3.事務平均響應時間

? 　4.事務成功率

從以下幾個方面來評定指標是否達標

- ①.給出產品性能的主要指標，如在100000記錄中查詢一個特定數據的時間為0.5秒；

- ②.以某個已發布的版本為基線，如比上一個版本的性能提高30-50%；

- ③.和競爭對手的同類產品比較。

|—5.2、服務器的性能指標——nmon工具

- ①.CPU利用率；

- ②.內存占用率；? 考慮是否存在內存泄漏的情況。

- ③.磁盤I/O ；

- ④.網絡?? 網絡帶寬

|—6、性能測試專業術語

性能測試要求的指標:性能測試需求上有說明，SE規定了要我們做哪些業務的性能，像：登錄，注冊，下單，查詢，添加購物車等，項目組只要求我們做了并發，壓測這塊。

|—6.1、并發數

一、經典公式1：

?? 一般來說，利用以下經驗公式進行估算系統的平均并發用戶數和峰值數據

? 1）平均并發用戶數為 C = nL/T

? 2）并發用戶數峰值 C‘ = C + 3*根號C

?? ? C是平均并發用戶數，n是login session的數量，L是login session的平均長度，T是值考察的時間長度

?? ? C’是并發用戶數峰值

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

平均并發用戶數為 C = 400*4/8=200

并發用戶數峰值? C`= 200 + 3*根號200=243

舉例2， 某公司為其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬信息，但并不是每個人都會用這個系統，假設只有50%的人會定期用該系統，這些人里面有70%是在每個月的最后一周使用一次該系統，且平均使用系統時間為5分鐘。

? 則一個月最后一周的平均并發用戶數為（朝九晚五）：

? n = 170000*0.5*0.7/5 = 11900

? C= 11900*5/60/8 = 124

|—6.2、響應時間（90%用戶的平均響應時間）

0.幾秒算好的，1.幾秒都算比較好的，<=3秒 都算正常，>3秒，分析下。超過5s以上性能是不達標。

|—6.3、吞吐率

100/sec

吞吐量計算為：F = Vu * R / T 單位為個/s? ?? 500 * 1/12s = 41.6請求數/sec? 1000 * 1/21s = 47.6/sec

|—6.4、吞吐量

指在一次性能測試過程中網絡上傳輸的數據量的總和（單位應該KB）,也可以這樣說在單次業務中，客戶端與服務器端進行的數據交互總量；對交互式應用來說，吞吐量指標反映服務器承受的壓力，容量規劃的測試中，吞吐量是重點關注的指標，它能夠說明系統級別的負載能力，另外，在性能調優過程中，吞吐量指標也有重要的價值；

并不是吞吐量越高越高，一個服務器的性能，要從多個方面去考慮：90%用戶的平均響應時間，錯誤率，吞吐量/吞吐量，CPU，內存，磁盤IO,網絡的占用情況，還有服務器的配置。

吞吐量/傳輸時間，即單位時間內網絡上傳輸的數據量，也可以指單位時間內處理客戶請求數量，它是衡量網絡性能的重要指標。

通常情況下，吞吐率用“字節數/秒”來衡量，當然，也可以用“請求數/秒”和“頁面數/秒”來衡量；

吞吐量/率和負載之間的關系：

①上升階段：吞吐量隨著負載的增加而增加，吞吐量和負載成正比；

②平穩階段：吞吐量隨著負載的增加而保持穩定，無太大變化或波動；

③下降階段：吞吐量隨著負載的增加而下降，吞吐量和負載成反比；

總結：吞吐量/率干不過負載！！！

|—6.5、內存泄漏（memory leak）

是指程序在申請內存后，無法釋放已申請的內存空間，導致系統無法及時回收內存并且分配給其他進程使用。通常少次數的內存無法及時回收并不會到程序造成什么影響，但是如果在內存本身就比較少獲取多次導致內存無法正常回收時，就會導致內存不夠用，最終導致內存溢出。

|—6.6、內存溢出（out of memory）：OOM

指程序申請內存時，沒有足夠的內存供申請者使用，或者說，給了你一塊存儲int類型數據的存儲空間，但是你卻存儲long類型的數據，那么結果就是內存不夠用，此時就會報錯OOM,即所謂的內存溢出，簡單來說就是自己所需要使用的空間比我們擁有的內存大內存不夠使用所造成的內存溢出。

|—6.7、內存溢出原因

1.內存中【加載的數據量過于龐大】，如一次從數據庫取出過多數據；

2.集合類中【有對對象的引用，使用完后未清空】，使得JVM不能回收；

3.代碼中存在死循環或循環產生過多重復的對象實體；

4.使用的第三方軟件中的BUG；

5.啟動參數內存值設定的過小

|—6.8、內存溢出的解決方案：

第一步，修改JVM啟動參數，直接增加內存。(-Xms，-Xmx參數一定不要忘記加。)

第二步，檢查錯誤日志，查看“OutOfMemory”錯誤前是否有其 它異常或錯誤。

第三步，對代碼進行走查和分析，找出可能發生內存溢出的位置。

|—6.9、重點排查以下幾點：

2.1.檢查對數據庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線后，數據庫中數據多了，一次查詢就有可能引起內存溢出。因此對于數據庫查詢盡量采用分頁的方式查詢。

2.檢查代碼中是否有死循環或遞歸調用。

3.檢查是否有大循環重復產生新對象實體。

4.檢查對數據庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線后，數據庫中數據多了，一次查詢就有可能引起內存溢出。因此對于數據庫查詢盡量采用分頁的方式查詢。

5.檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。

第四步，使用內存查看工具動態查看內存使用情況

|—7、性能測試流程

一、準備工作

1、首先要保證系統基礎功能驗證通過

性能測試在什么階段適合實施？切入點很重要！一般而言，只有在系統基礎功能測試驗證完成、系統趨于穩定的情況下，才會進行性能測試，否則性能測試是無意義的。

2、然后就是選擇好性能測試工具

綜合系統設計、工具成本、測試團隊的技能來考慮，選擇合適的測試工具，最起碼應該滿足一下幾點：

①支持對web（這里以web系統為例）系統的性能測試，支持http和https協議；

②工具運行在Windows平臺上；

③支持對webserver、前端、數據庫的性能計數器進行監控；

3、然后就是對預先的業務場景分析

為了對系統性能建立直觀上的認識和分析，應對系統較重要和常用的業務場景模塊進行分析，針對性的進行分析，以對接下來的測試計劃設計進行準備。

二、測試計劃

測試計劃階段最重要的是分析用戶場景，確定系統性能目標。

1、性能測試領域分析（也就是確定測試范圍，是需要做哪方面的性能測試，并發測試，壓力測試，疲勞測試，負載測試）

根據對項目背景，業務的了解，確定本次性能測試要解決的問題點；是測試系統能否滿足實際運行時的需要，還是目前的系統在哪些方面制約系統性能的表現，或者，哪些系統因素導致

系統無法跟上業務發展？確定測試領域，然后具體問題具體分析。

2、用戶場景剖析和業務建模

根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析，整理一個業務場景表，當然其中最好對用戶操作場景、步驟進行詳細的描述，為測試腳本開發提供依據。

3、確定性能目標（也就是確定各個用戶場景的性能指標）

前面已經確定了本次性能測試的應用領域，接下來就是針對具體的領域關注點，確定性能目標（指標）；其中需要和其他業務部門進行溝通協商，以及結合當前系統的響應時間等數據，確定

最終我們需要達到的響應時間和系統資源使用率等目標；比如：

①登錄請求到登錄成功的頁面響應時間不能超過2秒；

②報表審核提交的頁面響應時間不能超過5秒；

③文件的上傳、下載頁面響應時間不超過8秒；

④服務器的CPU平均使用率小于70%，內存使用率小于75%；

⑤各個業務系統的響應時間和服務器資源使用情況在不同測試環境下，各指標隨負載變化的情況等；

4、制定測試計劃的實施時間

預設本次性能測試各子模塊的起止時間，產出，參與人員等等。

三、測試腳本設計與開發

性能測試中，測試腳本設計與開發占據了很大的時間比重。

1、測試環境設計

本次性能測試的目標是需要驗證系統在實際運行環境中的性能外，還需要考慮到不同的硬件配置是否會是制約系統性能的重要因素！因此在測試環境中，需要部署多個不同的測試環境，

在不同的硬件配置上檢查應用系統的性能，并對不同配置下系統的測試結果進行分析，得出最優結果（最適合當前系統的配置）。

這里所說的配置大概是如下幾類：

①數據庫服務器

②應用服務器

③負載模擬器

④軟件運行環境，平臺

測試環境測試數據，可以根據系統的運行預期來確定，比如需要測試的業務場景，數據多久執行一次備份轉移，該業務場景涉及哪些表，每次操作數據怎樣寫入，寫入幾條，需要多少的

測試數據來使得測試環境的數據保持一致性等等。

可以在首次測試數據生成時，將其導出到本地保存，在每次測試開始前導入數據，保持一致性。

2、測試場景設計

通過和業務部門溝通以及以往用戶操作習慣，確定用戶操作習慣模式，以及不同的場景用戶數量，操作次數，確定測試指標，以及性能監控等。

3、測試用例設計

確認測試場景后，在系統已有的操作描述上，進一步完善為可映射為腳本的測試用例描述，用例大概內容如下：

用例編號：查詢表單_xxx_x1（命名以業務操作場景為主，簡潔易懂即可）

用例條件：用戶已登錄、具有對應權限等。。。

操作步驟：

①進入對應頁面。。。。。。

②查詢相關數據。。。。。。

③勾選導出數據。。。。。。

④修改上傳數據。。。。。。

PS：這里的操作步驟只是個例子，具體以系統業務場景描述；

4、腳本和輔助工具的開發及使用

按照用例描述，可利用工具進行錄制，然后在錄制的腳本中進行修改；比如參數化、關聯、檢查點等等，最后的結果使得測試腳本可用，能達到測試要求即可；

PS：個人而言，建議盡量自己寫腳本來實現業務操作場景，這樣對個人技能提升較大；一句話：能寫就絕不錄制！！！

四、測試執行與管理

在這個階段，只需要按照之前已經設計好的業務場景、環境和測試用例腳本，部署環境，執行測試并記錄結果即可。

1、建立測試環境

按照之前已經設計好的測試環境，部署對應的環境，由運維或開發人員進行部署，檢查，并仔細調整，同時保持測試環境的干凈和穩定，不受外來因素影響。

2、執行測試腳本

這一點比較簡單，在已部署好的測試環境中，按照業務場景和編號，按順序執行我們已經設計好的測試腳本。

3、測試結果記錄

根據測試采用的工具不同，結果的記錄也有不同的形式；現在大多的性能測試工具都提供比較完整的界面圖形化的測試結果，當然，對于服務器的資源使用等情況，可以利用一些計數器或

第三方監控工具來對其進行記錄，執行完測試后，對結果進行整理分析。

五、測試分析

1、測試環境的系統性能分析

根據我們之前記錄得到的測試結果（圖表、曲線等），經過計算，與預定的性能指標進行對比，確定是否達到了我們需要的結果；如未達到，查看具體的瓶頸點，然后根據瓶頸點的具體數據，

進行具體情況具體分析（影響性能的因素很多，這一點，可以根據經驗和數據表現來判斷分析）。

2、硬件設備對系統性能表現的影響分析

由于之前設計了幾個不同的測試環境，故可以根據不同測試環境的硬件資源使用狀況圖進行分析，確定瓶頸是再數據庫服務器、應用服務器抑或其他方面，然后針對性的進行優化等操作。

3、其他影響因素分析

影響系統性能的因素很多，可以從用戶能感受到的場景分析，哪里比較慢，哪里速度尚可，這里可以根據2\5\8原則對其進行分析；

至于其他諸如網絡帶寬、操作動作、存儲池、線程實現、服務器處理機制等一系列的影響因素，具體問題具體分析，這里就不一一表述了。

4、測試中發現的問題

在性能測試執行過程中，可能會發現某些功能上的不足或存在的缺陷，以及需要優化的地方，這也是執行多次測試的優點。

|—如何使用nmon工具檢測服務器的資源

1、工具獲取

下載地址：

http://sourceforge.jp/projects/sfnet_nmon/releases/ 或者直接從這獲取，還包含分析工具。可下載比較全的壓縮包：

nmon_linux_14i_newer_Linux_versions.tar.gz

官方地址：http://nmon.sourceforge.net/

2、使用

1. 解壓并獲取以對應平臺的nmon工具文件： nmon_linux_14i_newer_Linux_versions.tar.gz

解壓后，可以看到各個平臺的文件，我們只需要使用適合的即可，一般是nmon_linux_x86_64。

2. 將nmon工具文件上傳至服務器的相應目錄并增加可執行權限

a.? ? ? 上傳成功后：

b.? ? ? 增加可執行權限：

chmod 755 nmon_x86_64_centos6

3.使用nmon工具的實時監控功能

?輸入 ./ nmon_x86_64_centos6

3、數據采集

為了實時監控系統在一段時間內的使用情況并將結果記錄下來，我們可以通過運行以下命令實現：

$./nmon_x86_64_centos6 -ft? -m /nmon/log -s 1 -c 20

-f：按標準格式輸出文件：<hostname>_YYYYMMDD_HHMM.nmon；

-t：輸出中包括占用率較高的進程；

-m 切換到路徑去保存日志文件

-s 30：每30秒進行一次數據采集

-c 10：一共采集10次

-c 取出多少個抽樣數量，這里為120，即監控=120*(30/60/60)=1小時

??? 根據小時計算這個數字的公式為：c=h*3600/s，比如要監控10小時，每隔30秒采樣一次，則c=10*3600/30=1200

輸入命令回車后，將自動在當前目錄生成一個hostname_timeSeries.nmon的文件，如果hostname為svcpreapp01，生成的文件為：svcpreapp01_151221_1738.nmon，如下：

./nmon_x86_64_centos6 -ft -s 1 -c 10 &

4、生成報告(生成圖形化結果)

該命令啟動后，會在nmon所在目錄下生成監控文件，并持續寫入資源數據，直至360個監控點收集完成——即監控1小時，這些操作均自動完成，無需手工干 預，測試人員可以繼續完成其他操作。如果想停止該監控，需要通過“#ps –ef|grep nmon”查詢進程號，然后殺掉該進程以停止監控。

通過后臺監控和定期監控，我們可以得到擴展名為nmon的監控文件，這些文件記錄著系統資源的數據，需要配合分析工具（nmon analyser）進行解讀。

　　1)?? 使用FTP工具從服務器上取下生成結果文件/nmon/log/sjfx212_120318_1723.nmon到本機。

　　2)?? 打開nmon_analyser.zip 包下的nmon analyser v33g.xls 文件，點擊Analyse nomn data按鈕，選擇之前get下來的sjfx212_120318_1723.nmon文件。

5，數據分析

借助nmon analyser可以把nmon采集的數據生成直觀的Excel表，nmon analyser可以在IBM的官網下載，https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power+Systems/page/nmon_analyser

在windows上下載后解壓，有word和exce兩個文檔，Word是說明文檔，包括更新日志，詳細參數等，其中的Excel就是nmon analyser工具了。

Nmon 是一個分析aix和linux性能的免費工具（其主要是ibm為自己的aix操作系統開發的，但是也可以應用在linux操作系統上），而nmon_analyser是nmon的一個工具可以把nmon生成的報告轉化成excel報表的形式供我們查看。下面先讓看下nmon_analyser生成的報表。

|—1、安裝JMeter插

新的版本提供了插件管理器，但是需要自行下載安裝。

下載路徑：? https://jmeter-plugins.org/downloads/all/

放在lib/ext目錄下，然后重啟Jmeter，會在菜單-選項下多一個 Plugins Manager菜單，打開即可對插件進行安裝、升級。

|—2、Jmeter 插件安裝

打開 Plugins Manager 菜單，在可獲得的插件列表中選擇自己需要的插件進行安裝。

常用的插件：

? 支持Base64加解密等多個函數的插件?Custom JMeter Functions

? 用于服務器性能監視的?PerfMon Metrics Collector

? 用于建立壓力變化模型的?Stepping Thread Group

? 用于Json解析的?JSON Path Extractor

? 用于展示響應時間曲線的?Response Times Over Time

? 用于展示TPS曲線的?Transactions per Second

|—1、打開插件管理器Plugins Manager

可以看到：

? Installed Plugins： 已經安裝的插件

? Avaliable Plugins： 可以下載的其他插件

? Upgrades：一些插件的更新

|—2、比如我們要用自定義線程組這個插件，它不是默認安裝的，那就可以進入Avaliable Plugins 來下載安裝

搜索thread，選中 Custom Thread Groups,點擊 Apply Changes and Restart JMeter

3、重啟后就可以添加自定義線程組了

|—3、安裝自定義線程組

|—1、自定義線程組設計測試場景

JMeter中我們使用線程組來控制測試場景，原線程組無法設計復雜測試場景，所以要用到JMeter插件提

供的線程組元件Ultimate Thread Group 和 Stepping Thread Group。

|—2、插件安裝：

JMeter插件的安裝參考：https://blog.csdn.net/galen2016/article/details/92806212

什么是實際的性能測試？？？

1）思考時間：用戶在做不同操作之間有時間停頓，或者延遲，思考時間就是模擬用戶的操作過程中的停頓的間。

2）步伐，速度：主要包括，大量用戶進來的時間和退出時間，控制迭代之間的時間，例如，現場用戶20個，設置5秒內全部進入，就是這樣的情況。

3）壓力測試時間：假如需要500個人同時測試30分鐘，這里持續30分鐘就是壓測時間。

|—3、Ultimate Thread Group

一、簡單場景

100個線程，在10秒內加載完，然后持續運行600秒，最后在10秒內結束所有線程，如下圖：

參數說明：

? Start Threads Count：開始線程數量

? Initial Delay，sec：延時啟動當前行的線程，單位:秒

? Startup Time，sec：線程加載多長時間，單位:秒

? Hold Load For，sec：當前行線程達到峰值后的穩定加載時間，單位:秒

? Shutdown Time：線程在多長時間內停止下來，單位:秒

二、浪涌場景

說明：

第一次從0秒開始，在10秒內啟動100個線程，然后持續運行600秒，再在10秒內停止這100個線程

第二次從第620秒開始，在10秒內啟動100個線程，然后持續運行600秒，再在10秒內停止這100個線程

第三次第四次 依次類推，只需改動Initial Delay的值，本次Initial Delay的值=等于上一次的（Initial Delay+Startup Time+Hold Load For + Shutdown Time）

三、持續加壓場景

說明：

這是一個負載不斷增大的場景，有3條線程任務作業，每一個持續時間是600秒，100個線程運行600秒后再加100個，共300個線程。然后從第1810秒開始，沒10秒停止100個線程。整個場景共運行1840秒

注意：Hold Load For的值要從最后一個任務往前推算

|—4、Stepping Thread Group

下圖是100個線程按階梯狀遞增運行，每5秒內加載20個線程直到100，每個階梯是600秒，最后一個階梯是1000秒，即并發100個線程時，運行1000秒。最后每秒停止10個線程。

這是一個典型的負載測試場景，持續增加負載，檢驗服務器在不同負載下的性能。

參數說明：

? This group will start：加載多少線程

? First，wait for：等待多長時間開始加載線程

? Then start：初次加載多少個線程

? Next，add：下一次加載多少個線程

? Threads every：當前運行多長時間后再次加載線程

? Using ramp_up：加載線程時間

? Then hold load for：線程全部加載完成后運行多長時間

? Finally，stop /threads every：多長時間停止多少個線程

|—性能分析

排除法

1，響應是太長? 5s

1，中間件問題? apache中間件

?? ? ? ?? 添加中間件的線程數

?? ? ? ? ? ? ? linux? 查看當前http線程數量

?? ? ? ? ? ? ? ps -ef|grep httpd|wc -l

?? ? ? ? ? ? ? ps -ef 查看進程? grep httpd 過濾進程 httpd

?? ? ? ? ? ? ? wc -l? 統計數量

?? ? ? ? ? ? ? http.conf文件中 修改 最大連接數? ? ? ? ? ?

?? ? ? ? ? ? ? /etc/httpd/conf/httpd.conf

2、后臺代碼

?? ? a. 代碼架構合不合理

?? ? b. 代碼算法是否存在優化的空間

3、數據庫問題

?? ? a.查看數據庫的最大連接數

?? ?? mysql -u root -p123456

?? ?? 查詢最大連接數據：show VARIABLES like '%max_connect%'

?? ?? 最多? 支持3000-4000

?? ?? set GLOBAL MAX_CONNECTIONS=1000? 修改連接數

?? ? b.查看sql運行時間

?? ?? show full PROCESSLIST 展示所有sql運行的時間

?? ?? 如果 運行時間過長，進行sql語句優化? ??

?? ?? 1，進行sql優化

?? ?? 2，建立索引文件（增加查詢速度）? ??

??? c.索引緩存大小

?? ? ? show VARIABLES like 'key_buffer_size%'? 查看緩存空間大小

?? ? ? key_reads 從磁盤讀取數據

?? ? ? Key_read_requests 總的數據讀取

?? ? ? 命中率：

?? ? ? 命中率：

?? ? ? 命中率計算=key_reads/Key_read_requests*100=1.7%? ? ? ? ? ? ??

?? ? ? 命中率計算=key_reads/Key_read_requests*100%=1.7%

?? ? ? 當命中率 低于0.1% 算ok 高于0.1% 提高緩存空間大小

?? ? ? 當命中率小于0.01% 適當減少一些緩存空間大小

?? ? d，sleep過多

?? ? e，臨時表空間? ??

?4、 排除網絡問題? ? ? ? ? ? ? ?? #抓包數據

?? ?? 提升網絡帶寬? 200M? 看響應時間? 會不會大幅度縮短

?5，提升服務器硬件設備

?? ?? cpu，內存，磁盤

|—分布式壓測

一臺主控機，多臺客戶機

1、在主控機上編寫性能測試腳本

2、修改主控機的配置文件jemeter.properties文件，將所有的客戶機的IP地址及端口設置好

3、在主控機的Jmeter頁面啟動客戶機?

?? ? ? 運行->遠程啟動(指定啟動哪一臺）

?? ? ? 運行->遠程啟動所有

備注說明：如果客戶機不夠，也可以將主控機用來當成客戶機向服務器發請求，這里需要在jemeter.properties配置文件中把主控機的ip地址及端口加入，并啟動主控機的jmeter-server.bat文件即可。

所有客戶機的數據全部會自動發送給主控機，并進行分析。