一．系統吞度量要素：
吞吐量是指系統在單位時間內處理請求的數量
系統吞吐量幾個重要參數：QPS（TPS）、併發數、響應時間
QPS（TPS）：每秒鐘request/事務 數量
併發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把併發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 併發數/平均響應時間
併發數 = QPS*平均響應時間
舉個例子：
銀行窗口業務，窗口數量爲10個窗口，平均每個人辦理業務的時候爲2分鐘。可以用下面的方法計算。
併發數=10個窗口
平均響應時間爲 = 2分鐘
吞吐量 = 10/2 =5個每分鐘
真實的系統吞吐量：
如果一個系統接口在 4核8G的機器上跑
給接口分配4個線程，併發執行 ： 併發數= 4
平均響應時間是 100ms
QPS=4/0.1=40
提高吞吐量：
1. 併發數的優化：4個CPU
接口處理可能包括：CPU處理 20ms、 本地IO 30ms、網絡IO 50ms
可以在本地IO和網絡IO阻塞時，併發處理其他線程：每個線程任務真正佔用CPU的時間是 20ms
那麼，單個CPU100ms可以併發 5個線程，4個CPU*5=20個併發數
忽略線程切換的耗時：100ms 單個CPU可以併發5個線程，每個線程佔用CPU時間片20ms，等都執行完了，各自的IO也已經返回數據，再分別耗時1ms(忽略) 去接收IO返回
2. 響應時間優化：100ms優化到50ms
本地IO+網絡IO 增加響應的二級三級緩存，並優化網絡通信，可能可以提審一倍以上的性能，比如30ms
加上CPU處理耗時的20ms= 50ms
QPS=併發數20/響應時間50ms = 20/0.05 = 400QPS
一個系統吞吐量通常由QPS（TPS）、併發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降。
1. 併發數不變：QPS不斷增加，QPS超過最大吞吐量後，會有大量請求等待，平均響應時間急劇下降
2. QPS不變：增加併發數，會導致CPU併發線程過多，線上上下文切換頻繁，內存消耗增加，從而使平均響應時間下降
二．如何提高系統QPS？
由前面的公式：QPS（TPS）= 併發數/平均響應時間 可以看出，要提高qps,我們必須做2個方面努力
2.1增加併發數
1.比如增加tomcat併發的線程數，開喝服務器性能匹配的線程數，可以更多滿足服務請求。
2.增加數據庫的連接數，預建立合適數量的TCP連接數
3.後端服務儘量無狀態話，可以更好支持橫向擴容，滿足更大流量要求
4.調用鏈路上的各個系統和服務儘量不要單點，要從頭到尾都是能力對等的，不能讓其中某一點成爲瓶頸。
5.RPC調用的儘量使用線程池，預先建立合適的連接數。
2.2減少平均響應時間
1.請求儘量越前結束，越好，這樣壓力就不要穿透到後面的系統上，可以在各個層上加上緩存
2.流量消峯。放行適當的流量，處理不了的請求直接返回錯誤或者其他提示。和水壩道理很類似
3.減少調用鏈
4.優化程序
5.減少網絡開銷，適當使用長連接
6.優化數據庫，建立索引
最後，要優化的地方還有很多，上面只是列舉常見一些要注意的地方
優化的指導原則就是增加併發數 和減少平均響應時間
下面的內容整理引用其他博客，用於參考
三．系統吞吐量評估：
我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來QPS、併發數之外，還有另外一個維度：日PV。
通過觀察系統的訪問日誌發現，在用戶量很大的情況下，各個時間週期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關係（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高TPS，然後跟進1的關係，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶羣不一樣，這兩個客戶羣的網絡行爲不應用，他們之間的TPS和PV關係比例也不一樣。
A)淘寶
淘寶流量圖：
淘寶的TPS和PV之間的關係通常爲 最高TPS：PV大約爲 1 : 11*3600 （相當於按最高TPS訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）
B) B2B中文站
B2B的TPS和PV之間的關係不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關係（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，可能是因爲爬蟲暫的比例較高的原因導致。
在淘寶環境下，假設我們壓力測試出的TPS爲100，那麼這個系統的日吞吐量=100*11*3600=396萬
這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。
無論有無思考時間（T_think），測試所得的TPS值和併發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關係（穩定運行情況下）：
TPS=U_concurrent / (T_response+T_think)。
併發數、QPS、平均響應時間三者之間關係
上圖橫座標是併發用戶數。綠線是CPU使用率；紫線是吞吐量，即QPS；藍線是時延。
開始，系統只有一個用戶，CPU工作肯定是不飽合的。一方面該服務器可能有多個cpu，但是隻處理單個進程，另一方面，在處理一個進程中，有些階段可能是IO階段，這個時候會造成CPU等待，但是有沒有其他請 求進程可以被處理）。隨着併發用戶數的增加，CPU利用率上升，QPS相應也增加（公式爲QPS=併發用戶數/平均響應時間。）
隨着併發用戶數的增加，平均響應時間也在增加，而且平均響應時間的增加是一個指數增加曲線。而當併發數增加到很大時，每秒鐘都會有很多請求需要處理，會造成進程（線程）頻繁切換，反正真正用於處理請求的時間變少，每秒能夠處 理的請求數反而變少，同時用戶的請求等待時間也會變大，甚至超過用戶的心理底線。
軟件性能測試的基本概念和計算公式
一、軟件性能的關注點
對一個軟件做性能測試時需要關注那些性能呢？
我們想想在軟件設計、部署、使用、維護中一共有哪些角色的參與，然後再考慮這些角色各自關注的性能點是什麼，作爲一個軟件性能測試工程師，我們又該關注什麼？
首先，開發軟件的目的是爲了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。
對於用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來爲止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶並不知道我們後臺在做什麼。
用戶關注的是用戶操作的相應時間。
其次，我們站在管理員的角度考慮需要關注的性能點。
1、 響應時間
2、 服務器資源使用情況是否合理
3、 應用服務器和數據庫資源使用是否合理
4、 系統能否實現擴展
5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
6、 系統性能可能存在的瓶頸在哪裏
7、 更換那些設備可以提高性能
8、 系統能否支持7×24小時的業務訪問
再次，站在開發（設計）人員角度去考慮。
1、 架構設計是否合理
2、 數據庫設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的內存使用方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭
參考：