做性能測試時，你會發現有好多的專有名詞，什麼TPS、并發使用者數、吞吐量、吞吐率、響應時間等。那麼他們都是什麼意思呢？
一、術語解釋
1.響應時間
對請求作出響應所需要的時間
網絡傳輸時間：N1+N2+N3+N4
應用伺服器處理時間：A1+A3
資料庫伺服器處理時間：A2
響應時間=N1+N2+N3+N4+A1+A3+A2
是以，在讨論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。當然，往往也需要對每個或每組功能讨論其平均響應時間和最大響應時間。
響應時間的絕對值并不能直接反映軟體的性能的高低，軟體性能的高低實際上取決于使用者對該響應時間的接受程度。對于一個遊戲軟體來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對于編譯系統來說，完整編譯一個較大規模軟體的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于使用者來說都是可以接受的。
2.并發使用者數
并發使用者數是指系統可以同時承載的正常使用系統功能的使用者的數量。
并發使用者數是一個更直覺但也更籠統的性能名額。實際上，并發使用者數是一個非常不準确的名額，因為使用者不同的使用模式會導緻不同使用者在機關時間發出不同數量的請求。一網站系統為例，假設使用者隻有注冊後才能使用，但注冊使用者并不是每時每刻都在使用該網站，是以具體一個時刻隻有部分注冊使用者同時線上，線上使用者就在浏覽網站時會花很多時間閱讀網站上的資訊，因而具體一個時刻隻有部分線上使用者同時向系統送出請求。這樣，對于網站系統我們會有三個關于使用者數的統計數字：注冊使用者數、線上使用者數和同時發請求使用者數。由于注冊使用者可能長時間不登陸網站，使用注冊使用者數作為性能名額會造成很大的誤差。而線上使用者數和同僚發請求使用者數都可以作為性能名額。相比而言，以線上使用者作為性能名額更直覺些，而以同時發請求使用者數作為性能名額更準确些。
3.QPS（TPS）：每秒鐘request/事務 數量
QPS（TPS）= 并發數/平均響應時間
并發數、TPS、響應時間有什麼關系呢？來看個例子
QPS（TPS）= 并發數/平均響應時間 或者 并發數 = QPS*平均響應時間
一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鐘的時間裡使用者會登入簽到系統進行簽到。公司員工為1000人，平均每個員上登入簽到系統的時長為5分鐘。可以用下面的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間為 = 5*60 秒
并發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7
4.吞吐量與吞吐率
吞吐量是指系統在機關時間内處理請求的數量。不同系統的平均響應時間随使用者數增加而增長的速度也不大相同，這也是采用吞吐量來度量并發系統的性能的主要原因。一般而言，吞吐量是一個比較通用的名額，兩個具有不同使用者數和使用者使用模式的系統，如果其最大吞吐量基本一緻，則可以判斷兩個系統的處理能力基本一緻。
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等機關來衡量
從網絡角度看，吞吐量可以用：位元組/秒來衡量
對于互動式應用來說，吞吐量名額反映的是伺服器承受的壓力，他能夠說明系統的負載能力
以不同方式表達的吞吐量可以說明不同層次的問題，例如，以位元組數/秒方式可以表示數要受網絡基礎設施、伺服器架構、應用伺服器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用伺服器和應用代碼的制約展現出的瓶頸。
對于互動式應用來說，吞吐量名額反映的是伺服器承受的壓力，在容量規劃的測試中，吞吐量是一個重點關注的名額，因為它能夠說明系統級别的負載能力，另外，在性能調優過程中，吞吐量名額也有重要的價值。如一個大型工廠，他們的生産效率與生産速度很快，一天生産10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。
提示，用吞吐量來衡量一個系統的輸出能力是極其不準确的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強？是以，我們要加機關時間，看誰1秒鐘的出水量大。這就是吞吐率。
當沒有遇到性能瓶頸的時候，吞吐量與虛拟使用者數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /
其中F為吞吐量，VU表示虛拟使用者個數，R表示每個虛拟使用者發出的請求數，T表示性能測試所用的時間
二、如何提高軟體系統性能？
1.如何提高TPS？如何提升QPS？
1）減少CPU的使用時間（哪些代碼會消耗CPU：循環、字元串拼接\查找\替換、編碼\解碼、序列化\反序列化、壓縮）
2）增加CPU的數量
3）減少同步鎖
（如果CPU不能被壓到85%以上，并且此時的QPS已經達到了峰值，則說明另有瓶頸，接下去關注記憶體）
RT提升帶來什麼？
響應速度提升說明單詞請求的處理速度提升，使用者感覺任務處理速度更快，系統反應速度更快。當然在處理能力不變的情況下，RT的提升必然會提升QPS。
如何提升RT？
1）減少I/O的響應時間
2）減少I/O的調用次數
3）減少CPU使用時間（當然在I/O占大頭的應用裡，這方面優化效果肯定不明顯）
2.如何提高系統吞吐率？
(1)．系統吞度量要素：
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。
QPS（TPS）= 并發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、并發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景通路壓力下，隻要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導緻系統性能下降。
決定系統響應時間要素
我們做項目要排計劃，可以多人同時并發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計劃一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有CPU運算、IO、外部系統響應等等組成。
(2)．系統吞吐量評估：
我們在做系統設計的時候就需要考慮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、平均響應時間三者之間關系
來源：http://www.cnblogs.com/jackei/
參考資料：
1.http://www.ha97.com/5095.html
2.http://blog.csdn.net/yangzhenzhen/article/details/22305977
3.http://www.cnblogs.com/fnng/archive/2012/06/29/2570558.html