轉載原文: https://blog.csdn.net/hahavslinb/article/details/78673267

什么是性能測試？

壓力測試：強調極端暴力

穩(wěn)定性測試：在一定壓力下绪氛，長時間運行的情況

基準測試：在特定條件下的性能測試

負載測試：不同負載下的表現(xiàn)

容量測試：最優(yōu)容量

不同人群關注的性能指標各有側重。后臺服務接口的調用者一般只關心吞吐量、響應時間等外部指標院塞。后臺服務的所有者不僅僅關注外部指標俭正，還會關注CPU驯遇、內存、負載等內部指標鸿脓。

一. 外部指標: 從外部看抑钟，性能測試主要關注如下三個指標

1. 吞吐量：

每秒鐘系統(tǒng)能夠處理的請求數(shù)、任務數(shù)野哭。

吞吐量的指標受到響應時間在塔、服務器軟硬件配置、網絡狀態(tài)等多方面因素影響拨黔。

吞吐量越大蛔溃，響應時間越長。

服務器硬件配置越高篱蝇，吞吐量越大贺待。

網絡越差，吞吐量越小零截。

在低吞吐量下的響應時間的均值麸塞、分布比較穩(wěn)定，不會產生太大的波動涧衙。

在高吞吐量下哪工，響應時間會隨著吞吐量的增長而增長奥此，增長的趨勢可能是線性的，也可能接近指數(shù)的雁比。當吞吐量接近系統(tǒng)的峰值時稚虎，響應時間會出現(xiàn)激增。

一個系統(tǒng)的吞度量（承壓能力）與request對CPU的消耗偎捎、外部接口蠢终、IO等等緊密關聯(lián)。

單個reqeust?對CPU消耗越高茴她，外部系統(tǒng)接口寻拂、IO影響速度越慢，系統(tǒng)吞吐能力越低败京，反之越高兜喻。

系統(tǒng)吞吐量幾個重要參數(shù)：QPS（TPS）梦染、并發(fā)數(shù)赡麦、響應時間

????????QPS（TPS）：每秒鐘request/事務?數(shù)量

????????并發(fā)數(shù)：?系統(tǒng)同時處理的request/事務數(shù)

????????響應時間：??一般取平均響應時間

（很多人經常會把并發(fā)數(shù)和TPS理解混淆）

理解了上面三個要素的意義之后，就能推算出它們之間的關系：QPS（TPS）=?并發(fā)數(shù)/平均響應時間

2. 響應時間：

服務處理一個請求或一個任務的耗時帕识。

響應時間的指標取決于具體的服務泛粹。如智能提示一類的服務，返回的數(shù)據有效周期短（用戶多輸入一個字母就需要重新請求）肮疗，對實時性要求比較高晶姊，響應時間的上限一般在100ms以內。而導航一類的服務伪货，由于返回結果的使用周期比較長（整個導航過程中）们衙，響應時間的上限一般在2-5s。

對于響應時間的統(tǒng)計碱呼，應從均值蒙挑、.90、.99愚臀、分布等多個角度統(tǒng)計忆蚀，而不僅僅是給出均值。下圖是響應時間統(tǒng)計的一個例子

3. 錯誤率：

一批請求中結果出錯的請求所占比例姑裂。

錯誤率和服務的具體實現(xiàn)有關馋袜。通常情況下，由于網絡超時等外部原因造成的錯誤比例不應超過5%%舶斧，由于服務本身導致的錯誤率不應超過1% 欣鳖。

????????一個系統(tǒng)吞吐量通常由QPS（TPS）、并發(fā)數(shù)兩個因素決定茴厉，每套系統(tǒng)這兩個值都有一個相對極限值泽台，在應用場景訪問壓力下让网，只要某一項達到系統(tǒng)最高值，系統(tǒng)的吞吐量就上不去了师痕，如果壓力繼續(xù)增大溃睹，系統(tǒng)的吞吐量反而會下降，原因是系統(tǒng)超負荷工作胰坟，上下文切換因篇、內存等等其它消耗導致系統(tǒng)性能下降。

決定系統(tǒng)響應時間要素

我們做項目要排計劃笔横，可以多人同時并發(fā)做多項任務竞滓，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑吹缔，這條路徑就是項目的工期商佑。

系統(tǒng)一次調用的響應時間跟項目計劃一樣，也有一條關鍵路徑厢塘，這個關鍵路徑是就是系統(tǒng)影響時間茶没；

關鍵路徑是有CPU運算、IO晚碾、外部系統(tǒng)響應等等組成抓半。

我們在做系統(tǒng)設計的時候就需要考慮CPU運算、IO格嘁、外部系統(tǒng)響應因素造成的影響以及對系統(tǒng)性能的初步預估笛求。

而通常境況下，我們面對需求糕簿，我們評估出來的出來QPS探入、并發(fā)數(shù)之外，還有另外一個維度：日PV懂诗。

通過觀察系統(tǒng)的訪問日志發(fā)現(xiàn)蜂嗽，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣响禽。比如工作日的每天早上徒爹。只要能拿到日流量圖和QPS我們就可以推算日流量。

通常的技術方法：

????????1.?找出系統(tǒng)的最高TPS和日PV芋类，這兩個要素有相對比較穩(wěn)定的關系（除了放假隆嗅、季節(jié)性因素影響之外）

2.?通過壓力測試或者經驗預估，得出最高TPS侯繁，然后跟進1的關系胖喳，計算出系統(tǒng)最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣贮竟，這兩個客戶群的網絡行為不應用丽焊，他們之間的TPS和PV關系比例也不一樣较剃。

并發(fā)數(shù)、QPS技健、平均響應時間三者之間關系

二. 內部指標

從服務器的角度看写穴，性能測試主要關注CPU、內存雌贱、服務器負載啊送、網絡、磁盤IO等

CPU : top命令查看

后臺服務的所有指令和數(shù)據處理都是由CPU負責欣孤，服務對CPU的利用率對服務的性能起著決定性的作用馋没。

Linux系統(tǒng)的CPU主要有如下幾個維度的統(tǒng)計數(shù)據

us：用戶態(tài)使用的cpu時間百分比

sy：系統(tǒng)態(tài)使用的cpu時間百分比

ni：用做nice加權的進程分配的用戶態(tài)cpu時間百分比

id：空閑的cpu時間百分比

wa：cpu等待IO完成時間百分比

hi：硬中斷消耗時間百分比

si：軟中斷消耗時間百分比

下圖是線上開放平臺轉發(fā)服務某臺服務器上top命令的輸出，下面以這個服務為例對CPU各項指標進行說明

us & sy：大部分后臺服務使用的CPU時間片中us和sy的占用比例是最高的降传。同時這兩個指標又是互相影響的篷朵，us的比例高了，sy的比例就低婆排，反之亦然声旺。通常sy比例過高意味著被測服務在用戶態(tài)和系統(tǒng)態(tài)之間切換比較頻繁，此時系統(tǒng)整體性能會有一定下降泽论。另外艾少，在使用多核CPU的服務器上，CPU 0負責CPU各核間的調度翼悴，CPU 0上的使用率過高會導致其他CPU核心之間的調度效率變低。因此測試過程中CPU 0需要重點關注幔妨。

ni：每個Linux進程都有個優(yōu)先級鹦赎，優(yōu)先級高的進程有優(yōu)先執(zhí)行的權利，這個叫做pri误堡。進程除了優(yōu)先級外古话，還有個優(yōu)先級的修正值。這個修正值就叫做進程的nice值锁施。一般來說陪踩，被測服務和服務器整體的ni值不會很高。如果測試過程中ni的值比較高悉抵，需要從服務器Linux系統(tǒng)配置肩狂、被測服務運行參數(shù)查找原因

id：線上服務運行過程中，需要保留一定的id冗余來應對突發(fā)的流量激增姥饰。在性能測試過程中傻谁，如果id一直很低，吞吐量上不去列粪，需要檢查被測服務線程/進程配置审磁、服務器系統(tǒng)配置等谈飒。

wa：磁盤、網絡等IO操作會導致CPU的wa指標提高态蒂。通常情況下杭措，網絡IO占用的wa資源不會很高，而頻繁的磁盤讀寫會導致wa激增钾恢。如果被測服務不是IO密集型的服務瓤介，那需要檢查被測服務的日志量、數(shù)據載入頻率等赘那。

hi & si：硬中斷是外設對CPU的中斷刑桑，即外圍硬件發(fā)給CPU或者內存的異步信號就是硬中斷信號；軟中斷由軟件本身發(fā)給操作系統(tǒng)內核的中斷信號募舟。通常是由硬中斷處理程序或進程調度程序對操作系統(tǒng)內核的中斷祠斧，也就是我們常說的系統(tǒng)調用(System Call)泉褐。在性能測試過程中猫十，hi會有一定的CPU占用率，但不會太高浦妄。對于IO密集型的服務呢灶，si的CPU占用率會高一些吴超。

內存

性能測試過程中對內存監(jiān)控的主要目的是檢查被測服務所占用內存的波動情況。

在Linux系統(tǒng)中有多個命令可以獲取指定進程的內存使用情況鸯乃，最常用的是top命令鲸阻，如下圖所示

其中

VIRT：進程所使用的虛擬內存的總數(shù)。它包括所有的代碼缨睡，數(shù)據和共享庫鸟悴，加上已換出的頁面，所有已申請的總內存空間

RES：進程正在使用的沒有交換的物理內存（棧奖年、堆）细诸，申請內存后該內存段已被重新賦值

SHR：進程使用共享內存的總數(shù)。該數(shù)值只是反映可能與其它進程共享的內存陋守，不代表這段內存當前正被其他進程使用

SWAP：進程使用的虛擬內存中被換出的大小震贵，交換的是已經申請，但沒有使用的空間水评，包括（棧猩系、堆、共享內存）

DATA：進程除可執(zhí)行代碼以外的物理內存總量之碗，即進程棧蝙眶、堆申請的總空間

從上面的解釋可以看出，測試過程中主要監(jiān)控RES和VIRT，對于使用了共享內存的多進程架構服務幽纷，還需要監(jiān)沙發(fā)控SHR式塌。

LOAD（服務器負載）

Linux的系統(tǒng)負載指運行隊列的平均長度，也就是等待CPU的平均進程數(shù)

從服務器負載的定義可以看出友浸，服務器運行最理想的狀態(tài)是所有CPU核心的運行隊列都為1峰尝，即所有活動進程都在運行，沒有等待收恢。這種狀態(tài)下服務器運行在負載閾值下武学。

通常情況下，按照經驗值伦意，服務器的負載應位于閾值的70%~80%火窒，這樣既能利用服務器大部分性能，又留有一定的性能冗余應對流量增長驮肉。

Linux提供了很多查看系統(tǒng)負載的命令熏矿，最常用的是top和uptime

top和uptime針對負載的輸出內容相同，都是系統(tǒng)最近1分鐘离钝、5分鐘票编、15分鐘的負載均值

查看系統(tǒng)負載閾值的命令如下

在性能測試過程中，系統(tǒng)負載是評價整個系統(tǒng)運行狀況最重要的指標之一卵渴。通常情況下慧域，壓力測試時系統(tǒng)負載應接近但不能超過閾值，并發(fā)測試時的系統(tǒng)負載最高不能超過閾值的80%浪读，穩(wěn)定性測試時昔榴，系統(tǒng)負載應在閾值的50%左右。

網絡

性能測試中網絡監(jiān)控主要包括網絡流量瑟啃、網絡連接狀態(tài)的監(jiān)控论泛。

網絡流量監(jiān)控

可以使用nethogs命令。該命令與top類似蛹屿，是一個實時交互的命令，運行界面如下

在后臺服務性能測試中岩榆，對于返回文本結果的服務错负，并不需要太多關注在流量方面。

網絡連接狀態(tài)監(jiān)控

性能測試中對網絡的監(jiān)控主要是監(jiān)控網絡連接狀態(tài)的變化和異常勇边。對于使用TCP協(xié)議的服務犹撒，需要監(jiān)控服務已建立連接的變化情況（即ESTABLISHED狀態(tài)的TCP連接）。對于HTTP協(xié)議的服務粒褒，需要監(jiān)控被測服務對應進程的網絡緩沖區(qū)的狀態(tài)识颊、TIME_WAIT狀態(tài)的連接數(shù)等。Linux自帶的很多命令如netstat、ss都支持如上功能祥款。下圖是netstat對指定pid進程的監(jiān)控結果

磁盤IO:?iostat命令

性能測試過程中清笨，如果被測服務對磁盤讀寫過于頻繁，會導致大量請求處于IO等待的狀態(tài)刃跛，系統(tǒng)負載升高抠艾，響應時間變長，吞吐量下降桨昙。

Linux下可以用iostat命令來監(jiān)控磁盤狀態(tài)检号，如下圖

tps：該設備每秒的傳輸次數(shù)⊥芾遥“一次傳輸”意思是“一次I/O請求”齐苛。多個邏輯請求可能會被合并為“一次I/O請求”」鹑“一次傳輸”請求的大小是未知的

kB_read/s：每秒從設備（driveexpressed）讀取的數(shù)據量凹蜂，單位為Kilobytes

kB_wrtn/s：每秒向設備（driveexpressed）寫入的數(shù)據量，單位為Kilobytes

kB_read：讀取的總數(shù)據量藐俺，單位為Kilobytes

kB_wrtn：寫入的總數(shù)量數(shù)據量炊甲，單位為Kilobytes

從iostat的輸出中，能夠獲得系統(tǒng)運行最基本的統(tǒng)計數(shù)據欲芹。但對于性能測試來說卿啡，這些數(shù)據不能提供更多的信息。需要加上-x參數(shù)

rrqm/s：每秒這個設備相關的讀取請求有多少被Merge了（當系統(tǒng)調用需要讀取數(shù)據的時候菱父，VFS將請求發(fā)到各個FS颈娜，如果FS發(fā)現(xiàn)不同的讀取請求讀取的是相同Block的數(shù)據，F(xiàn)S會將這個請求合并Merge）

wrqm/s：每秒這個設備相關的寫入請求有多少被Merge了

await：每一個IO請求的處理的平均時間（單位是毫秒）

%util：在統(tǒng)計時間內所有處理IO時間浙宜，除以總共統(tǒng)計時間官辽。例如，如果統(tǒng)計間隔1秒粟瞬，該設備有0.8秒在處理IO同仆，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%裙品，該參數(shù)暗示了設備的繁忙程度俗批。

常見性能瓶頸

A:? 吞吐量到上限時系統(tǒng)負載未到閾值：一般是被測服務分配的系統(tǒng)資源過少導致的。測試過程中如果發(fā)現(xiàn)此類情況市怎，可以從ulimit岁忘、系統(tǒng)開啟的線程數(shù)、分配的內存等維度定位問題原因

B: CPU的us和sy不高区匠，但wa很高：如果被測服務是磁盤IO密集型型服務干像，wa高屬于正常現(xiàn)象。但如果不是此類服務麻汰，最可能導致wa高的原因有兩個速客，一是服務對磁盤讀寫的業(yè)務邏輯有問題，讀寫頻率過高什乙，寫入數(shù)據量過大挽封，如不合理的數(shù)據載入策略、log過多等臣镣，都有可能導致這種問題辅愿。二是服務器內存不足，服務在swap分區(qū)不停的換入換出忆某。

C: 同一請求的響應時間忽大忽小：在正常吞吐量下發(fā)生此問題点待，可能的原因有兩方面，一是服務對資源的加鎖邏輯有問題弃舒，導致處理某些請求過程中花了大量的時間等待資源解鎖癞埠；二是Linux本身分配給服務的資源有限，某些請求需要等待其他請求釋放資源后才能繼續(xù)執(zhí)行聋呢。

D: 內存持續(xù)上漲：在吞吐量固定的前提下苗踪，如果內存持續(xù)上漲，那么很有可能是被測服務存在明顯的內存泄漏削锰，需要使用valgrind等內存檢查工具進行定位通铲。

舉個 (栗子) 例子

智能提示服務趴窩了以后，必須立刻對其做性能摸底器贩。根據目前的情況颅夺，測試結果中需要提供外部指標和內部指標。

智能提示服務的架構和每個模塊的功能如下圖所示

從圖中我們可以看出蛹稍，測試前智能提示服務的底層數(shù)據服務已經確定了性能上限吧黄。因此，本次測試我們的任務是在底層數(shù)據服務性能為3500qps的前提下唆姐，找到智能提示服務上游各個模塊的性能上限拗慨。

一個完整的后臺服務性能測試流程如下圖所示。

測試前準備：

測試數(shù)據：由于智能提示已經在線上運行奉芦，本次測試使用智能提示趴窩那天的日志作為測試數(shù)據

QPS預估：本次測試就是為了找這個數(shù)

服務器配置：使用與線上軟硬件配置相同的服務器?

三. 壓測過程：

我們使用Jmeter發(fā)送測試數(shù)據來模擬用戶請求胆描，Jmeter測試配置文件使用的原件如下圖所示。從圖中可以看出仗阅，性能測試的配置文件主要由數(shù)據文件配置（線程間共享方式、到達末尾時的行為等）国夜、吞吐量控制减噪、HTTP采樣器（域名、端口、HTTP METHOD筹裕、請求body等）醋闭、響應斷言（對返回結果的內容進行校驗）。

數(shù)據文件配置

吞吐量控制

HTTP請求采樣

響應斷言

CPU

在linux中朝卒，sar证逻、top、ps等命令都可以對cpu使用情況進行監(jiān)控抗斤。一般來說囚企，最常用的是top命令。top命令的輸出如下：

top命令是一個交互式命令瑞眼，運行后會一直保持在終端并定時刷新龙宏。在性能測試中，可以使用如下參數(shù)讓top命令只運行一次

$top –n 1 –b –p ${pid}

服務器負載

linux中伤疙，服務器負載使用uptime命令獲取银酗，該命令的輸出如下圖

每一列的含義如下：

“當前時間 系統(tǒng)運行時長 登錄的用戶數(shù)最 近1分鐘、5分鐘徒像、15分鐘的平均負載”

內存

在linux中黍特， top、ps命令都可以對指定進程的內存使用狀況進行查看锯蛀。但最準確的信息在/proc/${PID}/status中灭衷，如下圖

上面命令的輸出中，我們重點關注VmRSS谬墙、VmData今布、VmSize

磁盤IO

磁盤監(jiān)控數(shù)據使用iostat命令獲取

測試報告輸出

在統(tǒng)計完性能測試過程中收集的監(jiān)控指標后，就可以輸出性能報告了拭抬。

通常來說部默，性能報告中要包含如下內容：

測試結論：包括被測服務最大QPS、響應時間等指標是否達到期望造虎，部署建議等傅蹂。

測試環(huán)境描述：包括性能需求、測試用服務器配置算凿、測試數(shù)據來源份蝴、測試方法等

監(jiān)控指標統(tǒng)計：響應時間統(tǒng)計、QPS氓轰、服務器指標統(tǒng)計婚夫、進程指標統(tǒng)計。建議最好用圖表來表示統(tǒng)計數(shù)據署鸡。?

結語

測試完畢后案糙，得出的結論是單臺智能提示服務的性能是300qps限嫌，線上整套智能提示服務的性能是1800qps；而月黑風高那天的流量大概是5000qps+时捌，難怪智能提示趴窩怒医，確實流量太大，遠超線上的吞吐容量奢讨。

其他描述:?

軟件性能的關注點

對一個軟件做性能測試時需要關注那些性能呢稚叹？

我們想想在軟件設計、部署拿诸、使用扒袖、維護中一共有哪些角色的參與，然后再考慮這些角色各自關注的性能點是什么佳镜，作為一個軟件性能測試工程師僚稿，我們又該關注什么？

首先蟀伸，開發(fā)軟件的目的是為了讓用戶使用蚀同，我們先站在用戶的角度分析一下，用戶需要關注哪些性能啊掏。

對于用戶來說蠢络，當點擊一個按鈕、鏈接或發(fā)出一條指令開始迟蜜，到系統(tǒng)把結果已用戶感知的形式展現(xiàn)出來為止刹孔，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間娜睛，當相應時間較小時髓霞，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間畦戒，在設計軟件時方库，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數(shù)據量查詢時障斋，我們可以將先提取出來的數(shù)據展示給用戶纵潦，在用戶看的過程中繼續(xù)進行數(shù)據檢索，這時用戶并不知道我們后臺在做什么垃环。

用戶關注的是用戶操作的相應時間邀层。

其次，我們站在管理員的角度考慮需要關注的性能點遂庄。

1寥院、 相應時間

2、 服務器資源使用情況是否合理

3涛目、 應用服務器和數(shù)據庫資源使用是否合理

4只磷、 系統(tǒng)能否實現(xiàn)擴展

5经磅、 系統(tǒng)最多支持多少用戶訪問、系統(tǒng)最大業(yè)務處理量是多少

6钮追、 系統(tǒng)性能可能存在的瓶頸在哪里

7、 更換那些設備可以提高性能

8阿迈、 系統(tǒng)能否支持7×24小時的業(yè)務訪問

再次元媚，站在開發(fā)（設計）人員角度去考慮。

1苗沧、 架構設計是否合理

2刊棕、 數(shù)據庫設計是否合理

3、 代碼是否存在性能方面的問題

4待逞、 系統(tǒng)中是否有不合理的內存使用方式

5甥角、 系統(tǒng)中是否存在不合理的線程同步方式

6、 系統(tǒng)中是否存在不合理的資源競爭

那么站在性能測試工程師的角度识樱，我們要關注什么呢嗤无？

一句話，我們要關注以上所有的性能點怜庸。

二当犯、軟件性能的幾個主要術語

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

網絡傳輸時間：N1+N2+N3+N4

應用服務器處理時間：A1+A3

數(shù)據庫服務器處理時間：A2

響應時間=N1+N2+N3+N4+A1+A3+A2

2割疾、并發(fā)用戶數(shù)的計算公式

系統(tǒng)用戶數(shù)：系統(tǒng)額定的用戶數(shù)量嚎卫，如一個OA系統(tǒng)，可能使用該系統(tǒng)的用戶總數(shù)是5000個宏榕，那么這個數(shù)量拓诸，就是系統(tǒng)用戶數(shù)。

同時在線用戶數(shù)：在一定的時間范圍內麻昼，最大的同時在線用戶數(shù)量奠支。

同時在線用戶數(shù)=每秒請求數(shù)RPS（吞吐量）+并發(fā)連接數(shù)+平均用戶思考時間

平均并發(fā)用戶數(shù)的計算：C=nL / T

其中C是平均的并發(fā)用戶數(shù)，n是平均每天訪問用戶數(shù)（login session）涌献，L是一天內用戶從登錄到退出的平均時間（login session的平均時間）胚宦，T是考察時間長度（一天內多長時間有用戶使用系統(tǒng)）

并發(fā)用戶數(shù)峰值計算：C^約等于C + 3*根號C

其中C^是并發(fā)用戶峰值，C是平均并發(fā)用戶數(shù)燕垃，該公式遵循泊松分布理論枢劝。

3、吞吐量的計算公式

指單位時間內系統(tǒng)處理用戶的請求數(shù)

從業(yè)務角度看卜壕，吞吐量可以用：請求數(shù)/秒您旁、頁面數(shù)/秒、人數(shù)/天或處理業(yè)務數(shù)/小時等單位來衡量

從網絡角度看轴捎，吞吐量可以用：字節(jié)/秒來衡量

對于交互式應用來說鹤盒，吞吐量指標反映的是服務器承受的壓力蚕脏，他能夠說明系統(tǒng)的負載能力

以不同方式表達的吞吐量可以說明不同層次的問題，例如侦锯，以字節(jié)數(shù)/秒方式可以表示數(shù)要受網絡基礎設施驼鞭、服務器架構、應用服務器制約等方面的瓶頸尺碰；已請求數(shù)/秒的方式表示主要是受應用服務器和應用代碼的制約體現(xiàn)出的瓶頸挣棕。

當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數(shù)之間存在一定的聯(lián)系亲桥，可以采用以下公式計算：F=VU * R /

其中F為吞吐量洛心，VU表示虛擬用戶個數(shù)，R表示每個虛擬用戶發(fā)出的請求數(shù)题篷，T表示性能測試所用的時間

4词身、性能計數(shù)器

是描述服務器或操作系統(tǒng)性能的一些數(shù)據指標，如使用內存數(shù)番枚、進程時間法严，在性能測試中發(fā)揮著“監(jiān)控和分析”的作用，尤其是在分析統(tǒng)統(tǒng)可擴展性户辫、進行新能瓶頸定位時有著非常關鍵的作用渐夸。

資源利用率：指系統(tǒng)各種資源的使用情況，如cpu占用率為68%渔欢，內存占用率為55%墓塌，一般使用“資源實際使用/總的資源可用量”形成資源利用率。

5奥额、思考時間的計算公式

Think Time苫幢，從業(yè)務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔垫挨，而在做新能測試時韩肝，為了模擬這樣的時間間隔，引入了思考時間這個概念九榔，來更加真實的模擬用戶的操作哀峻。

在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數(shù)量、每個用戶發(fā)出的請求數(shù)R和時間T的函數(shù)哲泊，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS

下面給出一個計算思考時間的一般步驟：

A剩蟀、首先計算出系統(tǒng)的并發(fā)用戶數(shù)

C=nL / T F=R×C

B、統(tǒng)計出系統(tǒng)平均的吞吐量

F=VU * R / T R×C = VU * R / T

C切威、統(tǒng)計出平均每個用戶發(fā)出的請求數(shù)量

R=u*C*T/VU

D育特、根據公式計算出思考時間

TS=T/R