柚子快報邀請碼778899分享：dubbo jmeter——下

http://yzkb.51969.com/

邏輯控制器

如果（if）控制器

??條件判斷滿足才執(zhí)行

??作用:If控制器用來控制它下面的測試元素是否運行

??位置:測試計劃-->線程組-->(右鍵添加)邏輯控制器-->如果(If）控制器

??可以與函數(shù)助手對話框搭配使用

??如果（if）控制器案例

????使用‘用戶定義的變量’定義一個變量name，name的值可以是baidu,根據(jù)name的變量值實現(xiàn)對應網(wǎng)站的訪問

????1．添加線程組

????2．用戶定義的變量

????3．添加If控制器，判斷name是否等于baidu

????不勾選Interpret condition,'$ {name } ' =='baidu'

????勾選，${__jexl3 ( ' $ {name } ' == 'baidu' ,) }

????4．添加HTTP請求，用來訪問百度

????5．添加if控制器，判斷name是否等于itcast

????6．添加HTTP請求，用來訪問傳智播客

????7．添加查看結(jié)果樹

事務控制器

??將多個步驟綁定為一個事務有一個步驟失敗事務就失敗了比如ATM機取錢

吞吐量控制器

??控制執(zhí)行百分比，例線程組設置線程數(shù)為10再建兩個吞吐量控制器設置吞吐量為30,10再執(zhí)行，一個執(zhí)行三次，一個執(zhí)行一次

循環(huán)控制器

??位置:測試計劃-->線程組-->(右鍵添加)邏輯控制器-->循環(huán)控制器

??參數(shù)介紹:

??案例:

??使用"循環(huán)控制器"的操作循環(huán)訪問百度10次步驟?

??1．添加線程組

??2．添加循環(huán)控制器—設置循環(huán)次數(shù)

??3．添加HTTP請求

??4．添加查看結(jié)果樹

ForEach控制器

??作用:一般和用戶自定義變量或者正則表達式提取器一起使用，讀取返回結(jié)果中一系列相關(guān)的變量值。該控制器下的取樣器都會被執(zhí)行一次或多次，每次讀取不同的變量值。

??位置:測試計劃-->線程組-->(右鍵添加）邏輯控制器-->ForEach控制器

WebService文件上傳接口

用戶場景：有一個新建用戶憑證頁面，填寫字段信息，上傳圖片文件，點擊提交，即新建成功。

WebSocket

WebSocket是一種網(wǎng)絡通信協(xié)議，客戶端和服務端只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進行雙向數(shù)據(jù)傳輸。

例

Server Name or IP：發(fā)送請求的目標服務器的IP地址或者域名。

Port Number：服務器地址后的端口號，有則填寫，沒有不用填寫。

Protocol [ws/wss]：ws是明文數(shù)據(jù)傳輸，wss是密文數(shù)據(jù)傳輸，相當于http和https的差別，默認ws。

Path：接口路徑。

Request data：發(fā)送的請求數(shù)據(jù)。

jmeter連接數(shù)據(jù)庫

jmeter命令行界面執(zhí)行

例：

#jmeter壓力測試,并使用命令生成詳細的html報告 jmeter -n -t C:\Users\Administrator\Desktop\HTTP請求.jmx -l D:\迅雷下載\res\res.jtl -e -o D:\迅雷下載\res\report #在非 GUI 模式下運行指定的 JMX 測試計劃文件，將測試結(jié)果保存為 res.jtl 文件，并生成一個 HTML 報告，最后將報告輸出到 D:\迅雷下載\res\report 目錄下。 --? #打印命令行選項并退出 -h, --help #打印使用信息并退出 -v, --version #打印版本信息并退出 -p, --propfile <參數(shù)> #要使用的 jmeter 屬性文件 -q, --addprop <參數(shù)> #額外的 JMeter 屬性文件 -t, --testfile <參數(shù)> #要運行的 jmeter 測試（.jmx）文件 -l, --logfile <參數(shù)> #將樣本記錄到的文件 -i, --jmeterlogconf <參數(shù)> #jmeter 日志配置文件（log4j2.xml） -j, --jmeterlogfile <參數(shù)> #jmeter 運行日志文件 (jmeter.log) -n, --nongui #在 nongui 模式下運行 JMeter -s, --server #運行 JMeter 服務器 -H, --proxyHost <參數(shù)> #為 JMeter 設置代理服務器以使用 -P, --proxyPort <參數(shù)> #設置 JMeter 使用的代理服務器端口 -N, --nonProxyHosts <參數(shù)> #設置非代理主機列表（例如 *. apache.org | localhost ） -u, --username <參數(shù)> #為 JMeter 使用的代理服務器設置用戶名 -a, --password <參數(shù)> #為 JMeter 使用的代理服務器設置密碼 -J, --jmeterproperty <參數(shù)>=<值> #定義額外的 JMeter 屬性 -G, --globalproperty <參數(shù)>=<值> #定義全局屬性（發(fā)送到服務器） 例如 -Gport = 123或 -Gglobal.properties -D, --systemproperty <參數(shù)>=<值> #定義附加系統(tǒng)屬性 -S, --systemPropertyFile <參數(shù)> #附加系統(tǒng)屬性文件 -f, --forceDeleteResultFile #在開始測試之前強制刪除現(xiàn)有的結(jié)果文件和網(wǎng)絡報告文件夾（如果存在） -L, --loglevel <參數(shù)>=<值> #[category=]level 例如 jorphan=INFO、jmeter.util=DEBUG 或 com.example.foo=WARN -r, --runremote #啟動遠程服務器（在 remote_hosts 中定義） -R, --remotestart <參數(shù)> #啟動這些遠程服務器（覆蓋 remote_hosts） -d, --homedir <參數(shù)> #要使用的 jmeter 主目錄 -X, --remoteexit #在測試結(jié)束時退出遠程服務器（CLI 模式） -g, --reportonly <參數(shù)> #僅從測試結(jié)果文件生成報告儀表板 -e, --reportatendofloadtests #負載測試后生成報告儀表板 -o, --reportoutputfolder <參數(shù)> #報表儀表板的輸出文件夾

性能理論

??滿足用戶需求

??最小成本

??評估系統(tǒng)性能

??功能測試后,項目上線前

??并發(fā):并發(fā)用戶數(shù)，并發(fā)請求數(shù)(QPS)

??TPS:每秒事務數(shù)(吞吐量)數(shù)值越大越好

??RT:響應時間2-5-8優(yōu)先以公司標準、各行業(yè)標準、行業(yè)通用失敗率

??CPU使用率越小越好，80%

指標（括展）

系統(tǒng)性能指標

??系統(tǒng)響應時間

????響應時間（Response Time: RT）指用戶從客戶端發(fā)起一個請求開始，到客戶端接收到從服務器端返回的響應結(jié)束，整個過程所耗費的時間。在性能檢測中一般以 壓力發(fā)起端至被壓測服務器返回處理結(jié)果的時間 為計量，單位一般為秒（s）或毫秒（ms）。

????平均響應時間指系統(tǒng)穩(wěn)定運行時間段內(nèi)，同一交易的平均響應時間。一般而言，交易響應時間都是指平均響應時間。 平均響應時間指標值應根據(jù)不同的交易分別設定，一般情況下，分為 復雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明確該交易在響應時間方面的特殊性。

????不同行業(yè)不同業(yè)務可接受的響應時間是不同的，一般情況，對于 在線實時交易：

互聯(lián)網(wǎng)企業(yè)：500 毫秒以下，例如淘寶業(yè)務 10 毫秒左右。 金融企業(yè)：1 秒以下為佳，部分復雜業(yè)務 3 秒以下。 保險企業(yè)：3 秒以下為佳。 制造業(yè)：5 秒以下為佳。

????對于 批量交易：

??????時間窗口：即整個壓測過程的時間，不同數(shù)據(jù)量則時間不一樣，例如雙 11 和 99 大促，數(shù)據(jù)量級不一樣則時間窗口不同。大數(shù)據(jù)量的情況下，2 小時內(nèi)可完成壓測。

??系統(tǒng)處理能力

????系統(tǒng)處理能力是指 系統(tǒng)在利用系統(tǒng)硬件平臺和軟件平臺進行信息處理的能力。系統(tǒng)處理能力通過 系統(tǒng)每秒鐘能夠處理的交易數(shù)量 來評價，交易有兩種理解：

一是業(yè)務人員角度的一筆業(yè)務過程； 二是系統(tǒng)角度的一次交易申請和響應過程。

????前者稱為業(yè)務交易過程，后者稱為事務。兩種交易指標都可以評價應用系統(tǒng)的處理能力。一般建議與系統(tǒng)交易日志保持一致，以便于統(tǒng)計業(yè)務量或者交易量。系統(tǒng)處理能力指標是技術(shù)測試活動中重要指標。

????一般情況下，用以下指標來度量：

HPS（Hits per Second）：每秒點擊次數(shù)，單位是次 / 秒。 TPS（Transaction per Second）：系統(tǒng)每秒處理交易數(shù)，單位是筆 / 秒。 QPS（Query per Second）：系統(tǒng)每秒處理查詢次數(shù)，單位是次 / 秒。

????對于互聯(lián)網(wǎng)業(yè)務中，如果某些業(yè)務有且僅有一個請求連接，那么 T P S = Q P S = H P S TPS=QPS=HPSTPS=QPS=HPS，一般情況下用 TPS 來衡量 整個業(yè)務流程，用 QPS 來衡量 接口查詢次數(shù)，用 HPS 來表示 對服務器單擊請求。

????無論 TPS、QPS、HPS，此指標是衡量系統(tǒng)處理能力非常重要的指標，越大越好，根據(jù)經(jīng)驗，一般情況下：

金融行業(yè)：1000 TPS ~ 50000 TPS，不包括互聯(lián)網(wǎng)化的活動。 保險行業(yè)：100 TPS ~ 100000 TPS，不包括互聯(lián)網(wǎng)化的活動。 制造行業(yè)：10 TPS ~ 5000 TPS。 互聯(lián)網(wǎng)電子商務：10000 TPS ~ 1000000 TPS。 互聯(lián)網(wǎng)中型網(wǎng)站：1000 TPS ~ 50000 TPS。 互聯(lián)網(wǎng)小型網(wǎng)站：500 TPS ~ 10000 TPS。

??并發(fā)用戶

????并發(fā)用戶數(shù)（Virtual User：VU）指在同一時刻內(nèi)，登錄系統(tǒng)并進行業(yè)務操作的用戶數(shù)量。

????并發(fā)用戶數(shù)對于 長連接系統(tǒng) 來說最大并發(fā)用戶數(shù)即是系統(tǒng)的并發(fā)接入能力。對于 短連接系統(tǒng) 而言最大并發(fā)用戶數(shù)并不等于系統(tǒng)的并發(fā)接入能力，而是與系統(tǒng)架構(gòu)、系統(tǒng)處理能力等各種情況相關(guān)。例如系統(tǒng)吞吐能力很強，加上短連接一般都有連接復用，往往并發(fā)用戶數(shù)大于系統(tǒng)的并發(fā)接入連接數(shù)。所以對于大部分短連接類型的系統(tǒng)，吞吐量模式（RPS 模式，Request Per Second）比較適合，也是阿里的最佳實踐，PTS 支持 RPS 模式的壓測，吞吐量的壓測構(gòu)建和衡量一步到位。 在測試中，采用虛擬用戶來模擬現(xiàn)實中用戶進行業(yè)務操作。

????一般情況下，性能測試是將 系統(tǒng)處理能力容量 測出來，而不是測試并發(fā)用戶數(shù)，除了服務器長連接可能影響并發(fā)用戶數(shù)外，系統(tǒng)處理能力不受并發(fā)用戶數(shù)影響，可以用最小的用戶數(shù)將系統(tǒng)處理能力容量測試出來，也可以用更多的用戶將系統(tǒng)處理能力容量測試出來。

????錯誤率

????錯誤率（Virtual Failure Ratio：FR）指系統(tǒng)在負載情況下，失敗交易的概率。錯誤率＝（失敗交易數(shù) / 交易總數(shù)）×100%。穩(wěn)定性較好的系統(tǒng)，其錯誤率應該由 超時 引起，即為超時率。

????不同系統(tǒng)對錯誤率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

資源指標

??CPU

????CPU 指標主要指的：CPU使用率、利用率，包括用戶態(tài)（user）、系統(tǒng)態(tài)（sys）、等待態(tài)（wait）、空閑態(tài)（idle）。

????CPU 使用率、利用率要低于業(yè)界警戒值范圍之內(nèi)，即小于或者等于 75%、CPU sys% 小于或者等于30%，CPU wait% 小于或者等于5%。單核 CPU 也需遵循上述指標要求。CPU Load 要小于 CPU 核數(shù)。

??內(nèi)存

????現(xiàn)代的操作系統(tǒng)為了最大利用內(nèi)存，在內(nèi)存中存放了緩存，因此內(nèi)存利用率 100% 并不代表內(nèi)存有瓶頸，衡量系統(tǒng)內(nèi)有瓶頸主要靠 SWAP（與虛擬內(nèi)存交換）交換空間利用率，一般情況下，SWAP 交換空間利用率要低于 70%，太多的交換將會引起系統(tǒng)性能低下。

??磁盤吞吐量

????磁盤指標主要有 每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數(shù)，平均服務時間，平均等待時間，空間利用率。其中 磁盤繁忙率 是直接反映磁盤是否有瓶頸的重要依據(jù)，一般情況下，磁盤繁忙率要低于70%。

??網(wǎng)絡吞吐量

????網(wǎng)絡吞吐量指標主要有 每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的 70%。

??內(nèi)核參數(shù)

????操作系統(tǒng)內(nèi)核參數(shù)主要包括 信號量、進程、文件句柄，一般不要超過設置的參數(shù)值即可

數(shù)據(jù)庫指標

??常用的數(shù)據(jù)庫例如ＭySQL，指標主要包括 SQL、吞吐量、緩存命中率、連接數(shù) 等

??SQL耗時越小越好，一般情況下微秒級別。

??命中率越高越好，一般情況下不能低于 95%。

??鎖等待次數(shù)越低越好，等待時間越短越好。

前端指標

??前端指標主要包括 頁面展示 和 網(wǎng)絡 所花的時間

??頁面要盡可能小及壓縮。

??頁面展示和花費時間越短越好。

穩(wěn)定性指標

??最短穩(wěn)定時間：系統(tǒng)按照 最大容量的 80% 或標準壓力（系統(tǒng)的預期日常壓力）情況下運行，能夠穩(wěn)定運行的最短時間。

??一般來說，對于正常工作日（8小時）運行的系統(tǒng)，至少應該能保證系統(tǒng)穩(wěn)定運行 8 小時以上。對于 7×24 運行的系統(tǒng)，至少應該能夠保證系統(tǒng)穩(wěn)定運行 24 小時以上。 如果系統(tǒng)不能穩(wěn)定的運行，上線后，隨著業(yè)務量的增長和長時間運行，將會出現(xiàn)性能下降甚至崩潰的風險。

??TPS 曲線穩(wěn)定，沒有大幅度的波動。

??各項資源指標沒有泄露或異常情況。

流程

??需求分析

??分析系統(tǒng)非功能需求（關(guān)注業(yè)務量、業(yè)務分布、用戶規(guī)模、性能指標等信息），確定性能測試范圍，了解性能指標。????一、系統(tǒng)非功能需求采集

??????（1）系統(tǒng)架構(gòu)：物理架構(gòu)（硬件及部署策略）和邏輯架構(gòu)（系統(tǒng)的功能與服務），包括中間件產(chǎn)品與配置、數(shù)據(jù)庫配置等，供我們搭建測試環(huán)境時進行參考。

??????（2）業(yè)務流程：業(yè)務量和業(yè)務分布。采集業(yè)務（分析出哪些業(yè)務納入性能測試范圍）并量化業(yè)務、業(yè)務擴展趨勢（年增長率或者未來的業(yè)務量）、業(yè)務發(fā)生時段（業(yè)務高峰的發(fā)生時間和高峰業(yè)務量）、業(yè)務分布（各項業(yè)務之間的比例）。

??????（3）用戶信息：在線用戶數(shù)、活動用戶數(shù)、業(yè)務分布。有些系統(tǒng)用戶量特別大，會對系統(tǒng)造成性能瓶頸，可以通過分析活動用戶數(shù)和業(yè)務分布來分析負載情況。

??????（4）系統(tǒng)是否與第三方系統(tǒng)有關(guān)，是否需要做擋板（Mock程序）。

??????（5）系統(tǒng)是否有歸檔機制：如果數(shù)據(jù)庫有歸檔機制，可以把一些無用或者過時的信息移到歸檔庫，這樣就減少當前數(shù)據(jù)庫的數(shù)據(jù)，有利于提高系統(tǒng)性能。

??????（6）性能指標：吞吐率、響應時間、事務成功率，CPU、內(nèi)存、磁盤、帶寬使用閥值。

????二、系統(tǒng)非功能需求分析

????確定性能測試范圍

是否核心業(yè)務，是否要求嚴格的質(zhì)量 是否高頻次的業(yè)務 是否占用系統(tǒng)較多資源、或性能影響大的業(yè)務 使用人數(shù)多還是少 在線人數(shù)多還是少 確定此功能的可測性、可驗證性：功能是否可驗證（是否牽連到第三方程序，是否需要做擋板Mock程序）。

????明確性能指標 業(yè)務性能指標 吞吐量（PV）、吞吐率（TPS等） 響應時間（RT）/ 應用響應時間（ART）：3秒以內(nèi) 事務成功率：99%以上 穩(wěn)定波動正常范圍

??測試策略

????負載測試 壓力測試 并發(fā)測試

????在文檔中明確列出測試范圍、人力投入、持續(xù)時間、工作內(nèi)容、風險評估、風險應對策略等。

系統(tǒng)概述：簡述系統(tǒng)使命、系統(tǒng)功能，用于給非專業(yè)人士了解系統(tǒng)是做什么的。 測試環(huán)境：生產(chǎn)環(huán)境、測試環(huán)境（服務器+負載機）的硬件架構(gòu)和詳細配置信息。 需求分析：需要測試的業(yè)務模型及其信息采集，性能指標的采集和確定。 測試策略：測試目的、測試執(zhí)行的可行性分析、具體的測試手段及測試監(jiān)控策略。 測試場景：如何組合業(yè)務場景進行性能測試。 測試準備：包括：測試工具的準備（負載工具、監(jiān)控工具、文檔管理工具）；測試腳本及測試程序準備；測試數(shù)據(jù)準備；測試環(huán)境準備。 時間計劃：進行需求分析、測試策略后，就可以相對合理的估算測試資源及耗時。 測試組織架構(gòu)：測試相關(guān)干系人，明確不同干系人的工作職責。 交付物清單：性能測試計劃、性能測試腳本、性能缺陷報告、性能測試階段性報告、性能測試報告（包括且不僅限于事務成功率、TPS、硬件性能指標等）。 系統(tǒng)風險：風險預測及風險評估（包括且不僅限于人員風險、軟件風險、進度風險、變更風險、系統(tǒng)風險、數(shù)據(jù)風險、環(huán)境風險），并提出應對策略。

??編寫腳本

????錄制腳本或手動開發(fā)，添加固定計時器模擬ThinkTime，增加同步定時器模擬集合點，增加IF條件控制器判斷邏輯，添加后置處理器獲取參數(shù)。腳本注意做斷言?。?！，驗證事務是否成功。 開發(fā)擋板程序，開發(fā)測試工具等。

????事務定義 合理的定義事務，能夠方便分析耗時（特別是混合業(yè)務功能場景測試），進而方便分析瓶頸。比如，購買商品，我們可以把下訂單定義為一個事務，把支付也定義為一個事務。

??執(zhí)行測試

????測試執(zhí)行是性能測試的關(guān)鍵，同樣的腳本不同執(zhí)行人員得出的結(jié)果可能差異較大。這些差異主要體現(xiàn)在場景設計與測試執(zhí)行上。

????場景設計 前面已經(jīng)確定了測試模型。場景設計是根據(jù)測試模型與目標，組織虛擬用戶、組合業(yè)務種類到一個測試單元。組織測試場景時盡量要與實際業(yè)務情況一致。

????基準測試 采用單業(yè)務場景、單用戶的方式執(zhí)行腳本。用于驗證測試環(huán)境、測試腳本，以及為后續(xù)的測試執(zhí)行提供性能基準。比如一個登錄系統(tǒng)，如果系統(tǒng)登錄時間為8秒，那么這個系統(tǒng)也就沒必要再進行性能測試，因為它連一般性能都達不到要求。

????配置測試 配置測試場景一般為混合場景（多個業(yè)務同時執(zhí)行），用于幫助分析系統(tǒng)軟、硬件配置是否滿足性能需求指標，優(yōu)化配置使各項資源達到最優(yōu)分配原則。測試過程是一個實驗過程，先是找出不合理配置，然后進行修改，最后進行驗證；周而復始到配置滿足需求。

????負載測試 負載測試的目的是分析性能變化趨勢，找出性能拐點分析性能問題與風險，對系統(tǒng)進行定容定量；為系統(tǒng)優(yōu)化、性能調(diào)整提供數(shù)據(jù)支撐。負載測試分為單場景與混合場景；單場景有利于分析性能問題，因為排除了其他業(yè)務干擾；混合場景更貼近用戶實際使用習慣，是一個綜合的性能評估。建議先做單場景測試再做混合場景測試。

????負載測試的性能變化曲線圖見前面的 “RT&TPS和Thread的趨勢圖”，①可以理解為單業(yè)務、單用戶時的系統(tǒng)性能，②通常是我們估算的滿足性能需求的點，③是性能拐點，之后性能變差，在這個點系統(tǒng)吞吐量達到最大，④這個點已經(jīng)過載，吞吐量開始減小。負載測試一般需要找到②③④這三個點，通常會因為一些配置、程序問題而受到干擾，所以執(zhí)行測試也是一個耗時的工作。

????穩(wěn)定性測試 穩(wěn)定性測試在正常性能閥值下盡量加大負載，長時間運行，確定系統(tǒng)的軟、硬件環(huán)境是否運行穩(wěn)定。什么是閥值呢？比如響應時間要求3s以內(nèi)，3秒就是閥值；比如CPU利用率70%以下，70%就是閥值。假設滿足性能要求的負載是B，那么穩(wěn)定性測試時負載一般是1.5B~2B。執(zhí)行時采用混合場景，按慣例執(zhí)行時間不低于8小時。時間上越長越好，有些隱藏較深的諸如內(nèi)存溢出的問題是需要長時間運行才能反映出來的。

??指標監(jiān)控

????響應時間

????吞吐量

????資源利用率

????并發(fā)處理能力

????中間件的使用情況

????數(shù)據(jù)庫指標

????穩(wěn)定性指標

??測試報告

????Jmeter測試報告的內(nèi)容介紹：

??????儀表盤統(tǒng)計：

????對于報告人來說，報告的是工作，是對整個測試過程的報告。對于決策層（報告相關(guān)干系人）來說關(guān)心的是結(jié)果，決策層迫切的想知道Yes or No，系統(tǒng)能不能上線，如果不能上線，有什么問題，怎么能夠盡快解決？這兩方面的需求決定了測試報告需要包含以下內(nèi)容。

性能測試背景：測試原因，性能測試開展的必要性。 性能測試目標：對系統(tǒng)進行定容定量、響應時間、配置、穩(wěn)定性等測試，風險評估。 性能測試范圍：參考測試計劃中的測試范圍。 名詞術(shù)語： 涉及專業(yè)名詞的解釋，參考測試計劃。 測試環(huán)境：報告結(jié)果基于的測試環(huán)境，不同的環(huán)境結(jié)果可能大相徑庭。 測試數(shù)據(jù)：報告測試數(shù)據(jù)量，參考測試計劃。 測試進度：報告測試過程，什么時候做什么工作，比如哪一天執(zhí)行了哪些測試腳本。 測試結(jié)果：基準測試、配置測試、負載測試、穩(wěn)定性測試等，全面多方位的報告測試結(jié)果，TPS、ART、事務成功率、硬件資源使用率（CPU、內(nèi)存、網(wǎng)絡、IO等）。 測試結(jié)論：分析給出測試結(jié)論，系統(tǒng)能否滿足性能要求？存在什么問題？有哪些缺陷？解決了哪些問題？還有哪些問題沒有解決？列出仍沒有解決的系統(tǒng)缺陷。 系統(tǒng)風險：報告系統(tǒng)可能存在的風險，幫助決策層應對風險。

常問問題

怎么驗證性能需求——執(zhí)行并發(fā)，根據(jù)項目指定的性能標準驗證。

壓力測試怎么做——找到系統(tǒng)最大并發(fā)，根據(jù)最大并發(fā)進行加倍壓測

??例：假如系統(tǒng)最大并發(fā)為200，第一次進行400并發(fā)壓測服務器沒崩繼續(xù)加進行600直至服務器崩了

????服務器崩的標準：失敗率突然從正常狀態(tài)一下子非常異常并且越來越高

??當前系統(tǒng)最大并發(fā)——注冊用戶30w，最大并發(fā)500-600

最大并發(fā)怎么找

??普通方法：

????并發(fā)tps = 總請求數(shù)/總時間

????只能滿足最基本的要求，但是不能很好覆蓋系統(tǒng)正常的使用情況

??二八原則：

????并發(fā)tps = 總請求數(shù) * 80% / 總時間 * 20%

????滿足系統(tǒng)絕大多數(shù)情況下的應用場景的需要

??根據(jù)業(yè)務運營數(shù)據(jù)的統(tǒng)計計算（通常用來做穩(wěn)定性測試）

????并發(fā)TPS = 有效請求數(shù) * 80% / 有效時間 * 20%

????當運營數(shù)據(jù)統(tǒng)計越精確時，計算出的并發(fā)TPS與實際的越接近

??根據(jù)用戶峰值業(yè)務操作來計算（通常用來做壓力測試）

????并發(fā)TPS = 峰值請求數(shù) / 峰值時間 * 系數(shù)

????滿足峰值請求時間段內(nèi)的負載量，系數(shù)取決于項目組對于未來業(yè)務量的評估

??進行壓測記錄

????例：最大并發(fā)200

??服務器由軟件硬件組成硬件最重要的有CPU、帶寬、內(nèi)存、硬盤

??服務器網(wǎng)站架構(gòu)：單機（性能很差）、集群（不同軟件部署到不同服務器然后連在一起構(gòu)成一個服務器）兩種

??代理：正向代理（整個過程用戶是一清二楚的）、反向代理（整個過程不透明）

柚子快報邀請碼778899分享：dubbo jmeter——下

http://yzkb.51969.com/

文章鏈接