https://www.cnblogs.com/york-hust/archive/2013/05/23/3094233.html
1、響應時間&響應率
客戶從發出請求到得到響應的整個時間； “TTLB”(Time to laster byte)，從發起一個請求開始，到客戶端收到最后一個字節的響應所耗費的時間。
紅色虛線 表求的是一種系統的理想狀態。 當服務器處理10個用戶請求時所用的時間是2秒（假設），當服務器處理200用戶請求時所用的時間也是2秒。 藍色斜線 是服務器常見的一種曲線狀態。 服務器的響應時間雖然用戶數量的增加逐漸變慢。 當系統出現這種斜線，應該說系統性能是相當健壯的。隨着用戶的增長響應時間逐漸變長。 黑色曲線 服務器處理能力的真實曲線狀態。 理發店模式 系統的拐角點 我們假設有一個門，在一個時間點上可同時過10個人，不管你是同時來3個還是10個都可以在同一時間點過門，假如來了11個人，必然有一個人要等10個人過門之后才能過。 那么當超過10人來過門時，過門的速度就開始變慢。那么10就是服務器性能的拐角點。我們通常做壓力測試找服務器的拐角點是很重要的任務之一。 測試的細度，影響圖像的結果
響應時間過程分析
呈現時間
不同瀏覽器顯示
操作系統、電腦硬件（cpu、內存）
數據傳輸時間
送信
發送請求時間、返回信息時間
壓測互聯網（局域網）
系統處理時間
系統得到請求后對請求進行處理並將結果返回
性能測試重點需要驗證的時間
用戶的電腦、網絡狀況不可控
系統處理時間可控
系統的的處理，語言、語言框架、中間件，數據庫、系統架構以及服務器系統。
實際的性能測試 現在的測試工具都屏蔽呈現過程，只是模擬多用戶並發請求，計算用戶得到響應的時間，頁不會將服務器的每個響應都向客戶端呈現。 對於數據傳輸的問題，強調的性能測試要在局域網中進行，在局域網中一般不會受到數據帶寬的限制。所以，可以對數據的傳輸時間忽略不計。
兩種情況：
訪問網頁首頁，圖片返回不完全
系統查詢數據，返回數據分頁
關於響應時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的區別。
合理的響應時間
互聯網用戶響應時間普通標准：2/5/10秒原則。
“非常有吸引力”-》“比較不錯”-》“糟糕”-》“失敗的請求”
考慮使用頻率
安裝系統
日常安裝軟件
稅務系統
“合理的響應時間”取決於用戶的需求，而不能依據測試人員自己設想來決定。
**
響應率 Request與Response是對應，一個請求對應一個響應。 但當客戶端對服務器的壓力達到一直程度后，不是每一請求都能得到響應的。 12306 "成功響應率也是很重要的一個指標。客戶端發送一千個請求的成功得到響應的幾率。 "
2、吞吐量&吞吐率
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力 如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。
提示，用吞吐量來衡量一個系統的輸出能力是極其不准確的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鍾，流出0.1噸水。 當然是一個水龍頭的吞吐量大。但是不能說1個水龍頭的出水能力是10個水龍頭的強 所以，我們要加單位時間，看誰1秒鍾的出水量大。這就是吞吐率。
吞吐率Ti & To 單位時間的吞吐量，吞吐量/秒。 吞吐量：單位時間內網絡上傳輸的數據量，也可以指單位時間內處理的客戶端請求數量。 “請求數/秒”、“字節數/秒”、“頁面數/秒”
不同的方式表達的吞吐量可以說明不同層次的問題。
例如，以字節數/秒方式表示的吞吐量主要受網絡基礎設置、服務器架構、應用服務器制約；以請求數/秒方式表示的吞吐量主要受應用服務器和應用代碼的制約。
站在服務器端，T-in表示“吞”；T-out表求“吐”
Ti：T-in 主要衡量服務器接受的請求數據包的吞吐率。
To： T-out 主要衡量的服務器端返回已處理數據包的吞吐率。
紅色虛線，表示一種理想的狀態。 隨着用戶數量的增加吞吐率也在持續增加。
黑色曲線，表示現實系統的吞吐率狀態。 剛開始吞吐率隨着用戶數量的增加逐漸變大，當大到一定程度時，逐漸平緩直到變成一條平線。 如果用戶還在持續增加中，那么吞吐率有可能下降，直到系統掛掉。
到了下班高峰期，車子變多，一下來了20輛，但這個路口的綠燈每天只能通過10輛，所以，這個時候，路口的通過率不會根據車輛的增加而繼續增加。 好的系統好像好有個好的交警在位置秩序，雖然車輛還在增加，但每個車輛都有條不紊等待通過路口。 不好的系統如路口趕上交警拉肚子，車輛在增加，后面車輛等得不耐煩就往前擠，結果稿得互不相讓。好嘛！之后還每個綠燈可通過10輛，現在只能有一輛車從夾縫中脫離苦海了。
響應時間圖與吞吐率圖並不是我們一輪性能測試下來就能得到結果。需要經過多輪測試才能得到。設置不同的用戶數量，得到每次的測試數據，將每次數據連接，從而得到最終系統性能曲線。關於用戶數量每次增加的數量自己把握。 每做完一輪測試后對數據進行分析，然后確定下輪測試所要設置的虛擬用戶數。
吞吐量指標的作用 用戶協助設計性能測試場景，以及衡量性能測試場景是否達到了預期的設計目標： 在設計性能測試場景時，吞吐量可被用戶協助設計性能測試場景，根據估算的吞吐量數據，可以對應到測試場景的事務發生頻率，事務發生次數等； 另外，在測試完成后，根據實際的吞吐量可以衡量測試是否達到了預期的目標。
用於協助分析性能瓶頸：
吞吐量的限制是性能瓶頸的一種重要表現形式，因此，有針對性地對吞吐量設計測試，可以協助盡快定位到性能冰晶所在位置。
3、qps和tps
事務 從業務的角度看，吞吐率=“業務數/小時或天”、“訪問人數/小時或天”、“頁面訪問量/小時或天”。銀行卡審批系統，“千件/小時”。 從用戶的角度，一個表單提交可以得到一次審批。又引出來一個概念---事務。 就是用戶某一步或幾步操作的集合。 某一個頁面的一次請求，系統的一次登錄，淘寶支付。衡量服務器對事務的處理能力----TPS TPS (Transaction Per second) 每秒鍾系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。
每秒處理的事務數目。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。
客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些信息作出的評估分。
TPS 的過程包括：客戶端請求服務端、服務端內部處理、服務端返回客戶端。
QPS（Queries Per Second） 是一台服務器每秒能夠響應的查詢次數 QPS = req/sec = 請求數/秒 qps與tps的區別 qps基本類似於tps 一次訪問，一次tps，多個qps 例如，訪問一個 Index 頁面會請求服務器 3 次，包括一次 html，一次 css，一次 js，那么訪問這一個頁面就會產生一個“T”，產生三個“Q”。
如果是對一個接口（單場景）壓測，且這個接口內部不會再去請求其它接口，那么TPS等於QPS，否則，TPS不等於QPS
計算公式： QPS（TPS）：每秒鍾request/事務 數量 並發數： 系統同時處理的request/事務數 響應時間： 一般取平均響應時間
QPS（TPS）= 並發數/平均響應時間 或者 並發數 =QPS（TPS）*平均響應時間
4、並發用戶數
提交請求的用戶總數 大家都知道我們的性能測試就通過工具模擬多用戶對系統進行操作，對系統造成壓力，來驗證系統的性能（不太標准的解釋）。好多人也簡單的把性能測試當成並發測試。 “多用戶”+“同時” 並發的兩種情況 嚴格意義上的並發：所有的用戶在同一時刻做同一件事或操作，同時刻登錄，同時提交表單。 廣義范圍的並發：請求或都操作可以是相同的，也可以是不同的。比如，在同時有的用戶在登錄，有的用戶在提交表單。 真正意義上的並發不存在 CPU在一個時間點上只能干一件事兒。 因為它很快，所以，它可以在多個程序之間快速瞬間的切換，給你造成的假象就是它在同時做這些事情。
神醫看病-》先分類、擴大接待室
神醫（CPU）-》接待人員、醫院（系統）-》病人（用戶）
所以，我們一般測試的目的是看醫院的接待能力-》系統能力
系統用戶數與同時在線人數 已注冊用戶數-》系統用戶數 同時登錄網站的人數-》同時在線人數
並發用戶數：取決於業務並發用戶數和業務場景，一般可以通過服務器日志的分析得到。
三一理發師理論 3名理發師，每個理發師剪一個頭發的時間是1個小時，每個客戶的接受的最長理發時間是3小時。
1位顧客：1名理發師。1小時，理發店服務1位顧客，顧客花費時間1小時； 兩位顧客 三位顧客 顧客數量從1位增加到3位的過程中，理發店的整體工作效率在提高，但是每位顧客在理發店內所呆的時間並未延長。 6位顧客 前三位所花費的時間均為1小時。后三位所花費的時間均為2小時 9位顧客，3位的“響應時間”為1小時，3位的“響應時間”為2小時（等待1小時+剪發1小時），3位的“響應時間”為3小時（等待2小時+剪發1小時）——已經到達用戶所能忍受的極限。 10位顧客，一定會有1位顧客因為“響應時間”過長而無法忍受，最終離開理發店走了。
這張圖中展示的是1個標准的軟件性能模型。 三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這里是指每秒事務數）以及響應時間（Response Time）。 橫軸：並發用戶數 最開始，隨着並發用戶數的增長，資源占用率和吞吐量會相應的增長，但是響應時間的變化不大； 並發用戶數增長到一定程度后，資源占用達到飽和，吞吐量增長明顯放緩甚至停止增長，而響應時間卻進一步延長。 並發用戶數繼續增長，軟硬件資源占用繼續維持在飽和狀態，但是吞吐量開始下降，響應時間明顯的超出了用戶可接受的范圍，並且最終導致用戶放棄了這次請求甚至離開。 根據這種性能表現，划分三個區域，Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受並放棄請求）。 在Light Load和Heavy Load 兩個區域交界處的並發用戶數，我們稱為“最佳並發用戶數（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個區域交界處的並發用戶數則稱為“最大並發用戶數（The Maximum Number of Concurrent Users）”。 當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待； 當系統負載處於最佳並發用戶數和最大並發用戶數之間時，系統可以繼續工作，但是用戶的等待時間延長，滿意度開始降低，並且如果負載一直持續，將最終會導致有些用戶無法忍受而放棄； 而當系統負載大於最大並發用戶數時，將注定會導致某些用戶無法忍受超長的響應時間而放棄。 理發店 最佳並發用戶數-》每小時3個顧客 最大並發用戶數-》每小時9個顧客 9個以后
對於一個確定的被測系統來說，在某個具體的軟硬件環境下，它的“最佳並發用戶數”和“最大並發用戶數”都是客觀存在。
最佳並發用戶數 以“最佳並發用戶數”為例，假如一個系統的最佳並發用戶數是50，那么一旦並發量超過這個值，系統的吞吐量和響應時間必然會 “此消彼長”；如果系統負載長期大於這個數，必然會導致用戶的滿意度降低並最終達到一種無法忍受的地步。 最佳並發用戶數要大於系統的平均負載。
當需要對一個系統長時間施加壓力——例如連續加壓3-5天，來驗證系統的可靠性或者說穩定性時，我們所使用的並發用戶數應該等於或小於“最佳並發用戶數”
最大並發用戶數
系統的最大並發用戶數要大於系統需要承受的峰值負載
5、CPU負載
CPU負載顯示的是一段時間內正在使用和等待使用CPU的平均任務數
CPU利用率高，並不意味着負載就一定大。 某公用電話亭，有一個人在打電話，四個人在等待，每人限定使用電話一分鍾，若有人一分鍾之內沒有打完電話，只能掛掉電話去排隊，等待下一輪。電話在這里就相當於CPU，而正在或等待打電話的人就相當於任務數。 在電話亭使用過程中，肯定會有人打完電話走掉，有人沒有打完電話而選擇重新排隊，更會有新增的人在這兒排隊，這個人數的變化就相當於任務數的增減。 為了統計平均負載情況，我們5秒鍾統計一次人數，並在第1、5、15分鍾的時候對統計情況取平均值，從而形成第1、5、15分鍾的平均負載。
有的人拿起電話就打，一直打完1分鍾，而有的人可能前三十秒在找電話號碼，或者在猶豫要不要打，后三十秒才真正在打電話。如果把電話看作CPU，人數看作任務，我們就說前一個人（任務）的CPU利用率高，后一個人（任務）的CPU利用率低。 當然， CPU並不會在前三十秒工作，后三十秒歇着，只是說，有的程序涉及到大量的計算，所以CPU利用率就高，而有的程序牽涉到計算的部分很少，CPU利用率自然就低。
但無論CPU的利用率是高是低，跟后面有多少任務在排隊沒有必然關系。
單核處理器 假設我們的系統是單CPU單內核的，把它比喻成是一條單向馬路，把CPU任務比作汽車。當車不多的時候，load <1；當車占滿整個馬路的時候 load=1；當馬路都站滿了，而且馬路外還堆滿了汽車的時候，load>1
多核處理器 我們經常會發現服務器Load > 1但是運行仍然不錯，那是因為服務器是多核處理器（Multi-core）。 假設我們服務器CPU是2核，那么將意味我們擁有2條馬路，我們的Load = 2時，所有馬路都跑滿車輛。
了解了CPU負載的含義，我們如何來降低服務器的CPU負載呢？ 最簡單辦法的是更換性能更好的服務器，不要想着僅僅提高CPU的性能，那沒有用，CPU要發揮出它最好的性能還需要其它軟硬件的配合。 在服務器其它方面配置合理的情況下，CPU數量和CPU核心數（即內核數）都會影響到CPU負載，因為任務最終是要分配到CPU核心去處理的。兩塊CPU要比一塊CPU好，雙核要比單核好。 因此，我們需要記住，除去CPU性能上的差異，CPU負載是基於內核數來計算的！有一個說法，“有多少內核，即有多少負載”。
CPU負載分擔到每個CPU上的負載是多少呢？那就要看我這台服務器有一共有多少個內核了。 假設服務器CPU型號為Intel(R) Xeon(R) CPU E5320，雙CPU，每個CPU都是雙核，相當於服務器有4個內核。 前面我們說CPU負載是基於CPU內核數計算的，那么以前十五分鍾的平均負載數10.49為例，我們可以得出，這台服務器每個CPU的負載為5.245，再分配到內核上，每個內核的負載為2.6左右。 CPU負載為多少才算比較理想 網上普通說法：CPU負載小於等於0.7算是一種理想狀態。 不管某個CPU的性能有多好，1秒鍾能處理多少任務，我們可以認為它無關緊要，雖然事實並非如此。在評估CPU負載時，我們只以5秒鍾為單位為統計任務隊列長度。如果每隔5秒鍾統計的時候，發現任務隊列長度都是1，那么CPU負載就為1。 假如我們只有一個單核的CPU，負載一直為1，意味着沒有任務在排隊，還不錯。
上面提到的我那台服務器，是雙核又CPU，等於是有4個內核，每個內核的負載為1的話，總負載為4。這就是說，如果我那台服務器的CPU負載長期保持在4左右，還可以接受。但實際上CPU負載已經達到9以上了，所以就很麻煩了。 但是每個內核的負載為1，並不能算是一種理想狀態！這意味着我們的CPU一直很忙，不得清閑。網上有說理想的狀態是每個內核的負載為0.7左右，我比較贊同，0.7乘以內核數，得出服務器理想的CPU負載，比如我這台服務器，負載在3.0以下就可以。
linux系統可以通過命令"w"查看當前load average情況
表示1分鍾/5分鍾/15分鍾內，一共有1.3/1.48/1.69個任務在使用和等待使用CPU
三種Load值，應該看哪個： 通常我們先看15分鍾load，如果load很高，再看1分鍾和5分鍾負載，查看是否有下降趨勢。 1分鍾負載值 > 1，那么我們不用擔心，但是如果15分鍾負載都超過1，我們要趕緊看看發生了什么事情。所以我們要根據實際情況查看這三個值
6、其它指標
CPU過高：說明出現硬件瓶頸，這時不管軟件如何優化，性能也提升不上去，需要從硬件着手；
內存：測試過程中，要觀察內存是否得到釋放，內存是否存在泄露、溢出；
IO：硬盤讀寫（例如：打開word文檔時會覺得慢，這時是在向硬盤讀這一塊的數據，點擊保存的時候，就是在往硬盤里面寫數據，也比較慢）。