0. 核心
前端-指標
響應時間：用戶從客戶端發出請求，並得到響應，以及展示出來的整個過程的時間。
加載速度：通俗的理解為頁面內容顯示的快慢。（改善：1. 減少HTTP重復請求；2.使用CDN；3. 減少下載的資源，壓縮，緩存等方法；）
電量：APP的耗電量（屏幕、GPS、喚醒機制、CPU、連網等的使用）。
流量：APP所消耗的流量（資源太多， 圖片太大， 重復請求， 日志上傳， 埋點數據）
Crash的原因一般有：空指針、內存泄漏、數組越界、調用了高版本的API。
ANR(Application Note Responding):主線程(即UI線程)在超時間內對用戶輸入時間沒有處理完畢時出現，用戶需要選擇等待或者強制關閉來殺死進程。
FPS（Frames Per Second）：動畫幀頻，1秒鍾時間里傳輸的圖片的量，越高越流暢，幀率達到60FPS以上，人眼主觀就感受不到差別了。所以一般以60FPS作為衡量標准，即要求每一幀刷新的時間小於16ms，這樣才能保證滑動中平滑的流暢度。
服務端-業務指標：
請求響應時間(TTLB)：對一個請求做出響應所需要的時間。
吞吐量throughput：網絡傳輸的數據量（處理客戶的請求數）
吞吐率：每秒請求數，每秒頁面數,用來識別性能瓶頸。
事務響應時間（TPS）：每秒事務數；tpm是每分鍾的事務數。
點擊率（HPS）:每秒點擊次數
並發用戶數：在同一時刻與服務器進行交互（指向服務器發出請求）的在線用戶數。
在線用戶數：指某段時間內，用戶訪問系統的用戶數。
注冊用戶數：軟件中已經注冊的用戶，這些用戶是系統的潛在用戶，隨時都有可能上線。
最佳並發用戶數：當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待
最大並發用戶數：系統的負載一直持續，有些用戶在處理而有的用戶在自己最大的等待時間內等待的時候
系統的平均負載：在特定的時間內，系統正在處理的用戶數和等待處理的用戶數的總和
峰值：指的是系統的最大能承受的用戶數的極值
業務成功率：多用戶對某一業務發起操作的成功率。
錯誤率：一段時間內出錯的請求在總請求數中的占比。
CAPS：每秒建立呼叫數量（Call Attempts Per Second）。
PV：頁面瀏覽量（Page View），或點擊量。
qps是指每秒內查詢次數，比如執行了select操作，相應的qps會增加。
不同的應用系統tps,qps是沒有可對比性的。
服務端-資源指標：
CPU：vmstat 使用率(us,sy,id)、運行隊列(r,b)和上下文切換(sc)
內存：vmstat 可用內存(free)，swap占用(swpd)，頁面交換(si,so)
Disk I/O：iostat 使用率（util），IOPS(磁盤每秒能IO次數, r/s,w/s)和數據吞吐量(rkB/s，wkB/s)
Network I/O: 網絡吞吐量（iptraf）
1. 性能測試
前提：開始的前提是被測系統的正常業務流程通過，即集成測試通過后。
操作：通過測試工具模擬多種正常、峰值及異常負載條件來對系統的各項性能指標進行測試。
目的：驗證軟件系統是否能夠達到用戶提出的性能指標，發現系統中存在的性能瓶頸並加以優化。
分類：4大類
- 基准測試：單用戶，發單次請求，產出基准性能數據。
- 負載測試：多用戶，用戶數漸增，持續同時發同一業務請求，產出最大TPS。
- 壓力測試：多用戶，資源使用飽和，持續同時發同一業務請求，產出系統瓶頸或使用極限。
- 混合場景測試：多用戶，資源使用不飽和，持續同時發不同業務請求，驗證系統穩定性。
在對互聯網服務進行服務端性能測試時，主要關注兩方面的性能指標：
1. 業務指標：如吞吐量(QPS、TPS)、點擊率(HPS)、響應時間(RT)、並發數、業務成功率等
2. 資源指標：如CPU、內存、Disk I/O、Network I/O等資源的消耗情況
2. 服務端-業務指標
2.1 請求響應時間(TTLB)
請求響應時間：對一個請求做出響應所需要的時間。響應時間是一個往返的過程，包括了客戶端請求和服務器響應的時間。可以模擬用戶的真實感受。
響應通常會稱為“TTLB”，即"time to last byte"，意思是從發起一個請求開始，到客戶端接收到最后一個字節的響應所耗費的時間，響應時間的單位一般為“秒”或者“毫秒”。
網絡傳輸時間：N1+N2+N3+N4
應用服務器處理時間：A1+A3
數據庫服務器處理時間：A2
響應時間=網絡響應時間+應用程序響應時間=（N1+N2+N3+N4）+(A1+A2+A3)
/** 標准可參考國外的3/5/10原則： （1）在3秒鍾之內，頁面給予用戶響應並有所顯示，可認為是“Very nice很不錯的”； （2）在3~5秒鍾內，頁面給予用戶響應並有所顯示，可認為是“Not bad好的”； （3）在5~10秒鍾內，頁面給予用戶響應並有所顯示，可認為是“Accept reluctantly勉強接受的”； （4）超過10秒就讓人有點不耐煩了，用戶很可能不會繼續等待下去，可認為是“Bye Bye再見”； */
還有一個是標准是2/5/8原則
平均響應時間：所有請求花費的平均時間，平均響應時間指針對某個業務的訪問統計所有的響應時間，然后求平均。
如：如果有100個請求，其中 98 個耗時為 1ms，其他兩個為 100ms
平均響應時間： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms並不能反映服務器的整體效率，因為98個請求耗時才1ms，引申出百分位數
百分位數：以響應時間為例，指的是 99% 的請求響應時間，都處在這個值以下，更能體現整體效率。
2.2 事務響應時間（TPS）
TPS（Transaction Per Second）每秒事務數，每秒鍾系統能夠處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.
事務：可以看作是一個動作或是一系列動作的集合，可能由一系列請求組成，例如登錄，從登錄開始到登錄結束為一個事務。
計算機術語中，事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。
在性能測試腳本設計中，事務的設置至少應該遵守原子性，即不可分割性。
常用的場景
1、事務=單個請求
2、事務=思考時間+單個請求
3、事務=多個相關聯的請求
/**
如果事務中增加思考時間，運行結果統計的事務響應時間是包括思考時間的，所有場景的設計，腳本的設置，對測試結果是有影響的，具體需要根據需求進行設計。 Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。
Think Time作用
A、降低當前運行時壓力，緩解對應用服務器所造成的壓力；
B、模擬真實生產用戶操作，考察對服務器所造成的影響。
0. 吞吐量公式
F = VU * R / T
其中F為吞吐量，
VU表示虛擬用戶個數，
R表示每個虛擬用戶發出的請求數，
T表示性能測試所用的時間
其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS 1. 平均的並發用戶數C，計算公式
C = nL / T
n：平均每天訪問用戶數（login session）
L：一天內用戶從登錄到退出的平均時間（login session的平均時間）
T：用戶每天使用系統大概多長時間，考察時間長度（一天內多長時間有用戶使用系統）
2. 計算思考時間的一般步驟： A、首先計算出系統的並發用戶數 C = nL / T
F = R × C B、統計出系統平均的吞吐量 F = VU * R / T
R × C = VU * R / T C、統計出平均每個用戶發出的請求數量 R = u * C * T / VU D、根據公式計算出思考時間 TS = T / R*/
TPS：衡量系統處理事務或交易的能力，即服務器對客戶請求的能力，每秒處理的事務數，一般在LoadRunner上使用，設置事務，然后統計單位時間內系統可以成功完成多少個定義的事務。
平均事務響應時間滿足了性能需求不一定表示系統的性能已經滿足了絕大多數用戶的要求，因而提出了90%事務響應時間。
90%事務響應時間指在一個時間切面上針對某個事務統計所有的響應時間，然后對這些響應時間進行排序，然后取其中90%的時間中最大的值（排序后的最后一個值）。
從計算平均響應時間的那些請求里去掉最慢的10%之后重新計算平均響應時間。
顯然，使用90%平均響應時間，因為去掉了出錯超時的那些請求，使得得到的數據更加接近真實值。
具體可以參考《LoadRunner 沒有告訴你的》之一——描述性統計與性能結果分析
如果某一次測出的TPS非常小，怎么辦？
可能的原因
1）服務器處理能力本如此
2）負載機的用戶數沒發出去，如給10個用戶，只發了3個用戶。如果是這種情況，可以用siege試一下
3）如果這時的CPU和內存占用也很小，可能是網卡滿了
2.3 吞吐量（率）
衡量網絡性能的重要指標
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、訪問人數/天、頁面訪問量/天、or 處理業務數/小時等單位來衡量。
從網絡角度看，吞吐量可以用：字節/秒來衡量
/** 對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力 以不同方式表達的吞吐量可以說明不同層次的問題，例如， 1. 以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸； 2. 已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。 當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R / T 其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間 */
吞吐率與很多因素有關，服務器的硬件配置，網絡的寬帶及拓撲結構，軟件的技術架構等。
2.4 並發用戶數
並發用戶數：主要是針對服務器而言，在同一時刻與服務器進行交互（指向服務器發出請求）的在線用戶數。
在線用戶數：指某段時間內，用戶訪問系統的用戶數，如多個用戶在瀏覽網頁，但沒有對同時對服務器進行數據請求，需要與並發用戶數區分開。
注冊用戶數：軟件中已經注冊的用戶，這些用戶是系統的潛在用戶，隨時都有可能上線。這個指標的意義在於讓測試工程師了解系統數據中的數據總量和系統最大可能有多少用戶同時在線。
平均的並發用戶數C，計算公式C=nL/T
n：平均每天訪問用戶數（login session）
L：一天內用戶從登錄到退出的平均時間（login session的平均時間）
T：用戶每天使用系統大概多長時間，考察時間長度（一天內多長時間有用戶使用系統）
峰值C1,即並發用戶峰值，計算公式C1=C+3*根號C，該公式遵循泊松分布理論。
/** 注：理解最佳並發用戶數和最大並發用戶數 看了《LoadRunner沒有告訴你的》之理發店模式，對最佳並發用戶數和最大的並發用戶數的理解小小整理了一下。 所謂的理發店模式，簡單地闡述一下， 一個理發店有3個理發師，當同時來理發店的客戶有3個的時候，那么理發師的資源能夠有效地利用，這時3個用戶數即為最佳的並發用戶數； 當理發店來了9個客戶的時候，3個客戶理發，而6個用戶在等待，3個客戶的等待時間為1個小時，另外的3個客戶的等待時間為2小時，客戶的最大忍受時間為3小時包括理發的1個小時，所以6個客戶的等待時間都在客戶的可以承受范圍內，故9個客戶是該理發店的最大並發用戶數。 */
具體的隨着並發用戶數的增加，響應時間R，吞吐量X，資源利用U 情況如下圖所示：
- Light Load（較輕壓力）
- 最佳用戶數（資源利用最高）
- Heavy Load（較重壓力，系統可以持續工作，但用戶等待時間較長，滿意度會下降）
- 最大並發用戶數
- Buckle Zone（用戶無法忍受而放棄請求）
最佳並發用戶數：當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待
最大並發用戶數：系統的負載一直持續，有些用戶在處理而有的用戶在自己最大的等待時間內等待的時候
系統的平均負載：在特定的時間內，系統正在處理的用戶數和等待處理的用戶數的總和
峰值：指的是系統的最大能承受的用戶數的極值
我們需要保證的是（反過來理解更容易）：
（1）最佳並發用戶數需大於系統的平均負載。如果系統的平均負載大於最佳並發用戶數，則用戶的滿意度會下降，所以我們需要保證系統的平均負載小於或者等於最佳並發用戶數
（2）系統的最大並發用戶數要大於系統需要承受的峰值負載。只有最大並發用戶數的大於系統所能承受的峰值負載，才不會造成等待空間資源的浪費，導致系統的效率低下
/** 補充： 並發一般分為2種情況。 1.嚴格意義上的並發，即所有的用戶在同一時刻做同一件事情或者操作，這種操作一般指做同一類型的業務。比如在信用卡審批業務中，一定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即所有用戶進行完全一樣的操作，例如在信用卡審批業務中，所有的用戶可以一起申請業務，或者修改同一條記錄。 2.廣義范圍的並發。這種並發與前一種並發的區別是，盡管多個用戶對系統發出了請求或者進行了操作，但是這些請求或者操作可以是相同的，也可以是不同的。對整個系統而言，仍然是有很多用戶同時對系統進行操作，因此也屬於並發的范疇。 可以看出，后一種並發是包含前一種並發的。而且后一種並發更接近用戶的實際使用情況，因此對於大多數的系統，只有數量很少的用戶進行“嚴格意義上的並發”。對於WEB性能測試而言，這2種並發情況一般都需要進行測試，通常做法是先進行嚴格意義上的並發測試。嚴格意義上的用戶並發一般發生在使用比較頻繁的模塊中，盡管發生的概率不是很大，但是一旦發生性能問題，后果很可能是致命的。嚴格意義上的並發測試往往和功能測試關聯起來，因為並發功能遇到異常通常都是程序問題，這種測試也是健壯性和穩定性測試的一部分。 用戶並發數量：關於用戶並發的數量，有2種常見的錯誤觀點。 一種錯誤觀點是把並發用戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統； 還有一種比較接近正確的觀點是把在線用戶數量理解為並發用戶數量。 實際上在線用戶也不一定會和其他用戶發生並發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，但是，在線用戶數量是計算並發用戶數量的主要依據之一。 */
Ramp-up time是規定所有用戶在時間段內把請求發送完。
2.5 點擊率（HPS）
每秒點擊次數Hits Per Second，是指在一秒鍾的時間內用戶對Web頁面的鏈接、提交按鈕等點擊總和。它一般和TPS成正比關系，是B/S系統中非常重要的性能指標之一。
點擊數：指Web Server收到的HTTP請求數。
點擊率：單位時間每秒用戶向Web Server提交的HTTP請求數。
區分鼠標點擊數：如請求一個網頁，網頁含有3張圖片，向Web Server請求的點擊數：1+3=4，而鼠標的一次點擊就可以訪問網頁，點擊數只有1次
2.6 業務成功率
2.7 錯誤率
一段時間內出錯的請求在總請求數中的占比。
對於錯誤率的容忍程度，取決於不同的系統需求。那么一般錯誤又分情況：
1有返回值的錯誤，這里又要分是HTTP請求之類的錯誤，還是業務上的錯誤。這些可能出現錯誤的值需要在測試腳本里做校驗，或者說斷言。
2 沒有返回值的錯誤，或者說就是超時。
有些請求會超時，那么不但會導致錯誤率的出現還會影響平均響應時間。
2.8 CAPS
每秒建立呼叫數量（Call Attempts Per Second）。
CAPS乘以3600就是BHCA（忙時呼叫量）了。 BHCA（Busy Hour Call Attempts）是忙時呼叫量的縮寫，
主要測試內容為：在一小時之內，系統能建立通話連接的絕對數量值。
測試結果是一個極端能力的反映，它反映了設備的軟件和硬件的綜合性能。BHCA值最后體現為CAPS(每秒建立呼叫數量)。
2.9 PV
頁面瀏覽量（Page View），或點擊量。同一個人瀏覽你網站同一個頁面，不重復計算pv量。pv就是一個訪問者打開了你網站的幾個頁面。pv的計算:當一個訪問者訪問的時候，記錄他所訪問的頁面和對應的IP，然后確定這個IP今天訪問了這個頁面沒有。如果你的網站到了24點，單純IP有60萬條的話，每個訪問者平均訪問了3個頁面，那么pv表的記錄就要有180萬條。
3.服務端-資源指標
指的是對不同的系統資源的使用程度,例如服務器的CPU利用率,磁盤利用率等.
資源利用率是分析系統性能指標進而改善性能的主要依據,因此是WEB性能測試工作的重點.
資源利用率主要針對WEB服務器,操作系統,數據庫服務器,網絡等,是測試和分析瓶頸的主要參考.
在實際測試中，通常會持續收集這些數據，如使用nmon，JMeter的PerfMon插件，以及zabbix等專門的系統監控工具
3.1 CPU
CPU的三個重要概念是我們需要關注的：使用率、運行隊列和上下文切換
1. CPU使用率(CPU Utilization Percentages)：有進程處於Running狀態的時間/總時間。
/** 在vmstat主要通過us、sys和id三列數據來體現：
· us：用戶占用CPU的百分比(消耗過高的原因可能是1.代碼問題；2.GC消耗) · sy：系統(內核和中斷)占用CPU的百分比（消耗高的原因上下文切換頻繁。上下文切換發生的情況有：中斷處理，多任務處理，用戶狀態改變。） · id：CPU空閑的百分比 性能測試指標中，CPU使用率通常用us + sy來計算，其可接受上限通常在70%~80%。
另外需要注意的是，在測試過程中，如果sy的值長期大於25%，應該關注in(系統中斷)和cs(上下文切換)的數值，並根據被測應用的實現邏輯來分析是否合理。 */
2. 運行隊列進程數(Processes on run queue)：Running狀態 + Waiting狀態的進程數。
/**
展示了正在運行和等待CPU資源的任務數，可以看作CPU的工作清單，是判斷CPU資源是否成為瓶頸的重要依據 vmstat通過r的值來體現： · r： 可運行進程數，包括正在運行(Running)和已就緒等待運行(Waiting)的。 如果r的值等於系統CPU總核數，則說明CPU已經滿負荷。
在負載測試中，其可接受上限通常不超過CPU核數的2倍。 */
3. 上下文切換(Context Switches)：簡單來說，context指CPU寄存器和程序計數器在某時間點的內容，(進程)上下文切換即kernel掛起一個進程並將該進程此時的狀態存儲到內存，然后從內存中恢復下一個要執行的進程原來的狀態到寄存器，從其上次暫停的執行代碼開始繼續執行至頻繁的上下文切換將導致sy值增長。
/** vmstat通過cs的值來體現： · cs：每秒上下文切換次數。 */
4. 平均負載Load Average：在一段時間內的平均負載，系統工具top、uptime等提供1分鍾、5分鍾和15分鍾的平均負載值。
/** 在UNIX系統中，Load是對系統工作量的度量。Load取值有兩種情況，多數UNIX系統取運行隊列的值(vmstat輸出的r,Running)， 而Linux系統取運行隊列的值 + 處於task_uninterruptible狀態的進程數(vmstat輸出的b,Blocked)，所以會出現CPU使用率不高但Load值很高的情況。
[hbase@ecs-097 ~]$ top
top - 19:23:28 up 18:05, 3 users, load average: 0.80, 0.60, 0.53
上面示例中的0.80即是1分鍾內的Load average，以此類推。
當我們需要了解當前系統負載情況時，可以先查看Load average的值，
如果系統持續處於高負載(如15分鍾平均負載大於CPU總核數的兩倍)，
則查看vmstat的r值和b值來確認是CPU負荷重還是等待I/O的進程太多。
*/
CPU良好狀態指標：
-
- CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。
- 上下文切換：與CPU利用率相關聯，如果CPU利用率狀態良好，大量的上下文切換也是可以接受的。
- 可運行隊列：每個處理器的可運行隊列<=3個線程。
3.2 內存
/** 內存包括物理內存和虛擬內存 物理內存和硬盤上的一塊空間(SWAP)組合起來作為虛擬內存(Virtual Memory)為進程的運行提供一個連續的內存空間，
好處：進程可用的內存變大了，
缺點：SWAP的讀寫速度遠低於物理內存，並且物理內存和swap之間的數據交換會增加系統負擔。 虛擬內存被分成頁(x86系統默認頁大小為4k)，內核讀寫虛擬內存以頁為單位，當物理內存空間不足時，內存調度會將物理內存上不常使用的內存頁數據存儲到磁盤的SWAP空間，物理內存與swap空間之間的數據交換過程稱為頁面交換(Paging)。 */
/** vmstat輸出free的值，可用內存過小將影響整個系統的運行效率 對於穩定運行的系統，free可接受的范圍通常應該大於物理內存的20%，即內存占用應該小於物理內存的80%。 在壓力測試時，系統內存資源的情況應該用可用內存結合頁面交換情況來判斷，如果可用內存很少，但頁面交換也很少，此時可以認為內存資源還對系統性能構成嚴重影響。 */
2. SWAP空間占用:
/** 可以從vmstat的swpd來獲取當前SWAP空間的使用情況， 應該和頁面交換結合來分析，比如當swpd不為0，但si，so持續保持為0時，內存資源並沒有成為系統的瓶頸。 */
3. 頁面交換(Paging)：頁面交換包括從SWAP交換到內存和從內存交換到SWAP，如果系統出現頻繁的頁面交換，需要引起注意。
/** 可以從vmstat的si和so獲取： · si：每秒從SWAP讀取到內存的數據大小 · so：每秒從內存寫入到SWAP的數據大小 */
Memory良好狀態指標
- swap in （si） == 0，swap out （so） == 0
- 應用程序可用內存/系統物理內存 <= 70%
3.3 Disk I/O
/**
磁盤通常是系統中最慢的一環，
一是其自身速度慢，即使是SSD(固態硬盤)，其讀寫速度與內存都還存在數量級的差距，
二是其離CPU最遠。另外需要說明的是磁盤IO分為隨機IO和順序IO兩種類型，在性能測試中應該先了解被測系統是偏向哪種類型。
隨機IO：隨機讀寫數據，讀寫請求多，每次讀寫的數據量較小，其IO速度更依賴於磁盤每秒能IO次數(IOPS)。
順序IO：順序請求大量數據，讀寫請求個數相對較少，每次讀寫的數據量較大，順序IO更重視每次IO的數據吞吐量(每秒數據量)。
*/
良好狀態指標
iowait % < 20%
提高命中率的一個簡單方式就是增大文件緩存區面積，緩存區越大預存的頁面就越多，命中率也越高。Linux 內核希望能盡可能產生次缺頁中斷（從文件緩存區讀），並且能盡可能避免主缺頁中斷（從硬盤讀），這樣隨着次缺頁中斷的增多，文件緩存區也逐步增大，直到系統只有少量可用物理內存的時候 Linux 才開始釋放一些不用的頁。
磁盤I/O高居不下，通過什么來查看占用I/O的進程？iotop,監視磁盤I/O使用狀況的top類工具。
3.4 Network I/O
網絡本身是系統中一個非常復雜的部分，但常規的服務端性能測試通常放在一個局域網進行，因為我們首先關注被測系統自身的性能表現，並且需要保證能在較少的成本下發起足夠大的壓力。
因此對於多數系統的性能測試，我們主要關注網絡吞吐量即可，對於穩定運行的系統，需要為被測場景外的業務留出足夠的帶寬；在壓力測試過程中，需要注意瓶頸可能來自於帶寬。
1. 在Linuxf服務器，可以使用iptraf來查看本機網絡吞吐量，如：
/** [root@ecs-097 ~]# iptraf -d eth0 x Total rates: 67.8 kbits/sec Broadcast packets: 0x x 54.2 packets/sec Broadcast bytes: 0x x x Incoming rates: 19.2 kbits/sec x x 25.4 packets/sec x x IP checksum errors: 0 x x Outgoing rates: 48.7 kbits/sec x x 28.8 packets/sec */
2. 網絡帶寬：單位時間（一般指的是1秒鍾）內能傳輸的數據量。
服務器網卡一般都是千兆，我們可以確認一下，先用ifconfig來看下當前服務器的網卡，是eth0；另外，lo是本地環路接口。
用ethtool查詢網卡信息，下面顯示的速度Speed是1000Mb/s，注意，這里是Mb，不是MB。
通過sar命令（sar -n DEV 1）查看網絡情況，rxkB/s表示每秒接收的數據量。
也可以使用tcpdump抓包，然后Wireshark分析tcpdump抓包結果
3. 良好狀態指標
對於UDP：接收、發送緩沖區不長時間有等待處理的網絡包。 watch netstat -su
對於TCP：不會出現因為緩存不足而存在丟包的事，因為網絡等其他原因，導致丟了包，協議層也會通過重傳機制來保證丟的包到達對方。所以，tcp而言更多的專注重傳率。
cat /proc/net/snmp | grep Tcp:
4. 通用指標
通用指標（指Web應用服務器、數據庫服務器必需測試項)
5. Web服務器指標
6. 數據庫服務器指標
7. 系統的瓶頸定義
8. 網址測試標准
9. 性能測試通過標准
1、所有計划的測試已經完成。
2、所有計划收集的性能數據已經獲得。
3、所有性能瓶頸得到改善並達到設計要求。
針對規定的功能模塊進行性能測試，分析在最大用戶的情況下，事務的90 Percent Time值，是否在2、5、8s以內，服務器的CPU使用率<=75%，內存使用率<=70%，事務的通過率=100%。
10. 經典性能測試場景
tps常常是有限制的，如cpu<80%,內存<60%時的tps
cpu使用率和內存占用率往往是默認的或取經驗值
容量測試：一般可設置運行1小時
壓力測試：一般可設置10分鍾
穩定測試：7*24小時、5*24小時
很不明確的需求：一般測試最大TPS
11. 性能測試用例（框架）
12. 性能調優的本質
- 拿時間換空間
- 拿空間換時間
時間：響應時間
空間：緩存
摘錄網址
- 性能測試中服務器關鍵性能指標淺析(1)
- 性能測試中服務器關鍵性能指標淺析(2)
- 軟件測試網-性能測試
- 澤眾軟件
- 常見的性能測試指標
- Performance Testing Guidance for Web Applications
- blazemeter:https://www.blazemeter.com/blazemeter/
- web性能測試基本性能指標
- 性能測試指標
- 性能測試基礎
- 性能測試的指標