系統性能描述
描述一個系統的性能從來不是一句話或是一個數值的事。在IEEE的定義中：性能是系統或組件在給定約束中實現的指定功能的程度，諸如速度、正確性、內存使用等。
所以性能測試報告中，對系統性能的描述應該是多方面的，如：執行效率、穩定性、兼容行、可靠性、可擴展性容量等；其中，執行效率通過併發用戶數、響應時間、吞吐量、成功率、資源消耗綜合體現。
併發測試
性能測試有：負載測試、壓力測試、配置測試、併發測試、容量測試、穩定性測試。其中，併發測試是測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題。
在實際的壓測中，我們基本上都是設置多個併發，再進行負載測試、壓力測試等，因爲現實中，我們的系統就是面對多個用戶的同時使用，並且，併發用戶的數量，直接影響着系統資源的消耗，例如cpu、mem、網絡連接、帶寬，甚至於系統內部邏輯。
併發怎麼看？
所謂併發，它的特點是“並行”和“同時”。
LoadRuner的併發很好理解，就是虛擬用戶數。因爲LR有個集合點，可以在所有虛擬用戶初始化且到達集合點後，再一起執行後續操作，從而達到同時且並行的效果。
但目前在後臺性能測試，我們自己開發的工具大多不帶集合點功能，這時候使用者對併發的理解就會有點混亂。下面以長連接壓測爲例：
最簡單的一種，一個單進程單線程send工具，啓動一次連續發m個包，這種其實屬於單併發，請求串是一個接一個串行到達壓測對象，一般都要再簡單封裝下，類似多進程併發：
注意這樣還是串行執行，下面這種才能起到併發的作用。
另一種是單進程多線程模式，可以配置起多個線程，一個線程發起一個連接到達壓測對象，n個線程就有n個連接，
以上三種情況，假設所有線程極致同步且系統性能足夠，那麼同一時間內（或者說同一瞬間），應該是有等同線程個數的請求同時到達系統，並同時被處理完再一起返回，此時線程就是併發，線程數就是併發數，這裏理解應該沒有問題。
但實際上，所有的併發不可能做到完全同步，壓測過程中由於各種影響，比如：各線程初始化速度不一樣，連接數不夠，處理速度不一樣等，導致在並行節奏上相互有了偏差， 這種現象在系統接近性能瓶頸時，會更加突出。所以會有同學疑問，這還能叫“併發”嗎？ 這裏引入“狹義併發”和“廣義併發”的概念。
“廣義的併發實際上是在一個時間內操作事務的虛擬用戶，而狹義的併發指的是單位時間內向系統發起請求的虛擬用戶，前者是“存在”，後者是“請求”，勿容置疑，壓力不僅僅受成功發出請求的用戶帶來的壓力，同時也受“存在”的用戶影響。”
http://www.cnblogs.com/pohome/articles/2073283.html
這樣看來，工具中的線程數設置，更偏像是廣義併發，代表着在壓測時間段內虛擬用戶總數，這也是併發原始值。而在後續的壓測過程中，在單位時間內，併發數可能會動態變化，這裏是狹義併發。
當工具產生的壓力遠未到系統性能瓶頸時，理論上，狹義併發=廣義併發=工具線程數；當壓力增加，系統響應時間增長，部分線程的請求處理正常，部分線程可能請求超時，那麼同一單位時間內，同時向系統發起請求的用戶數就不等於線程數了。
那麼我們如何實時掌握壓測過程中可能變化的併發？
《Method for Estimating the Number of Concurrent Users》一文介紹了一種併發估算法（網上有很多相關資料，這裏不再累述）：
C：併發
n：壓測時間段內所有的請求數
L：平均響應時間
T：壓測總時長
這裏注意：L（平均響應時間）≠ T（總時長）/ n（總請求）
壓力是什麼？
壓力就是併發在單位時間內對壓測對象的請求數。在我們的壓測工具中，有一個配置項專門用來設置壓力，可能是所有線程產生的總壓力，也可能是單個線程產生的壓力。
有些同學會在這裏納悶，爲什麼我設置了發送10w筆/s的請求，系統吞吐量的計算只有1w筆/s，是不是工具有問題？這裏是因爲混淆了壓力和性能。
“壓力不等於性能，壓力只是檢驗性能的一種手段，對一個性能良好的系統，在一定的壓力下，應該可以保持正常運轉，如果超過負荷，則應該分流或化解壓力，這也是我們需要檢驗的”
http://www.cnblogs.com/pohome/articles/2073283.html
例如：100個併發，1s內發送1w筆請求，如果系統的吞吐量計算大於或等於1w筆/s，說明系統承受住100個併發，1w/s的壓力，我們可以增加壓力繼續測試，直到出現性能拐點；如果系統的吞吐量計算是5k筆/s，則說明，如果我們需要系統應付100個併發，1w/s的壓力，解決方案要麼提升系統性能一倍，要麼擴容一臺分流壓力。
要特別注意：壓力是由工具製造，工具的最大性能決定施加的最大壓力。我們在測試過程中曾經遇到壓測系統還沒到極限，工具已經到瓶頸的情況，這時候得到的壓測數據是錯誤的。
吞吐量如何計算？
我們在壓測工具製作中，一直存在一個爭議——吞吐量的計算。
在性能測試中，吞吐量的計算有兩種常見的公式：
公式1： 吞吐量=併發數/平均響應時間
公式2： 吞吐量=請求總數/總時長
公式1、2大家應該都接觸過，雖然看上去不一樣，其實理論上都是ok的。首先我們可以從C = nL / T 推導：
併發=請求總數*平均響應時間 / 總時長
=》併發 / 平均響應時間 = 請求總數 / 總時長
=》公式1 = 公式2
然後我們構建三組模型進一步論證：
第一組模型
一共有4個線程，同時發了4筆請求，其中3筆耗時1s，一筆耗時2s，整個過程一共耗時2s。
公式1：
平均響應時間 = （1+1+1+2）/ 4= 1.25s ;
併發 = nL/T =4*1.25/2 =2.5
吞吐量 = 2.5 / 1.25 = 2 筆/s
公式2：
吞吐量 = 總筆數/總耗時 = 4/2= 2 筆/s
第二組模型
一共有4個線程，同時發了4筆請求，4筆請求耗時均爲1s，1s內全部發送完畢。
公式1：
平均響應時間 = （1+1+1+1）/ 4= 1s
併發 = nL/T =4*1/1 =4
吞吐量 = 4 / 1= 4 筆/s
公式2：
吞吐量 = 總筆數/總耗時 = 4 / 1= 4 筆/s
第三組模型
一共有4個線程，4筆請求耗時均爲1s，但線程發送出現不同步現象，一共持續1.5s完成全部：
公式1：
平均響應時間 = （1+1+1+1）/ 4= 1s
併發 = nL/T =4*1/1.5 =2.67
吞吐量 = 2.67 / 1= 2.67 筆/s
公式2：
吞吐量 = 總筆數/總耗時 = 4 / 1.5 = 2.67 筆/s
從我們構建的模型上看，兩個公式計算的結果是相等的。但是，這種平衡是建立在併發穩定的基礎上，併發如果變化，結果就會有差異。下面我們看一組真實的壓測數據
從上圖中看出，實際壓測時，兩個公式還是會有些微差別，這就是因爲我們本來預想併發應該=工具線程數，但在壓測過程中，實際併發發生了變化，我們再反推下實際的併發數
計算出的實際併發確實稍低於工具線程數。
結論
1、 在單接口壓測時，我們用“請求總數/總時長”得到吞吐量；然後再用“吞吐量*平均響應時間”得到實際併發，此舉可用來觀察系統實際承受的併發；
2、 在多接口壓測時，由於短板效應，同一個流程中的所有接口獲得的請求總數和總時長都一樣，顯然“請求總數/總時長”計算各個子接口的吞吐量不合適，所以改用“併發/平均響應時間”，其中的併發數應在壓測工具中埋點統計，不可簡單使用工具線程數。