不過相信敏銳的你能看出來，第一部分咱們的討論裏，包含了大量與服務器性能類似的概念。
剛好，老王
除了開了一家開封菜餐廳，還運營着一家網站=_=!。
這家網站的一次典型事務請求鏈路是這樣的：
你別說，還真挺像用餐流程的吧。
並且就像多人用餐的場景同樣，這個網站一樣也有多用戶請求的狀況：
當一條請求從客戶端發起時，它遵循着以上的線路傳遞，線性完成。
老王發現，這家網站的性能關鍵，在於應用服務器上。就像餐廳的服務能力，主要取決於後廚團隊同樣。
當多個客戶端同時發起請求時，服務器必須具有必定的「並行」能力，不然後續進來請求會排隊並且可能超時。
說到這呢，雖然上圖咱們畫的是一個，但通常都服務器的都有多處理器,輔以超線程技術。
而主流編程語言都有「多線程編程」的概念，其目的就在於合理的調度任務，將CPU的全部處理器充分的利用起來。
也就是說咱們能夠認爲，這套應用服務自己就有不止一個「大廚」在烹飪。
取決於處理器數和多線程技術，數個事務能夠以線程的方式並行處理。
不過老王對於當前服務器的性能並不滿意，就像對於餐廳同樣，老王也針對這個應用服務思考了更多調優方案：
- 大廚的數量真的夠嗎？是否是要繼續增長人數（CPU核數，服務器節點數-硬件調優）？
- 大廚的經驗和技術到位嗎？是否是要改聘更資深的大廚（改換具備更高頻CPU的服務器-硬件調優；調整業務邏輯效率-邏輯調優）？
- 改良熱門餐品的備菜策略？（利用數據庫索引、緩存等技術-邏輯調優）
除了咱們強調的調優重點，應用服務/後廚團隊，其餘部分也是有可能成爲瓶頸，須要調優解決的，好比：
- 餐廳容量會不會沒法容納排隊的客戶？（服務器容量，線程池大小，最大鏈接數，內存空間）
- 小二的下單和上菜速度有沒有成爲掣肘？（網絡帶寬，路由效率等。對於數據密集型服務而言，網絡帶寬極可能成爲瓶頸。）
- 等等
3. 下面是性能測試環節
接下來咱們要討論如何測試一套服務的性能。
線程數：
要實現性能測試的一個必要條件，那就是咱們必需要能模擬高峯期的訪問量。這一點經過正常的應用客戶端是很難辦到的（好比web應用的客戶端就是瀏覽器，你很難用瀏覽器併發向服務器發送大量請求）。
這裏就須要性能測試工具來幫忙了，主流的性能測試工具好比，等都能以線程式併發的方式，幫咱們達成「短期內向服務器發送大量請求」這一任務。
多線程式併發測試工具，顧名思義，會啓動複數個線程，讓每一個線程獨立向服務器端發出請求。
有時候咱們在描述性能測試過程時，會將這個客戶端的獨立線程數表述爲「併發數」。
可是注意，這裏的「併發」指的是客戶端併發，很簡單，客戶端能發出不少請求，服務器卻未必能處理得了是否是？
並行數：
那麼服務器一次性能同時處理多少事務請求呢？
根據咱們以前的討論，同一時間節點上同時處理的事務數最大就是：CPU處理器數*服務器超線程倍率。
好比對於一個8核未超線程CPU，某時間節點上的同時處理的事務不會超過8個。類比於8個廚師，同一時間點上只能處理8份餐品。
而超線程技術就像是給廚師們來了一場「左右互搏」培訓，讓每一個人都能一心二用，一次處理2份餐品。
這裏咱們描述的「同時8個」事務，就是「並行/平行」的含義。
併發數：
注意上面咱們討論的「並行數」，不是"併發數"。不然咱們直接看CPU核數就能肯定併發數了。
併發數指的是一個時間段內的事務完成數。這個切片「時間段」常取1秒鐘或1分鐘這樣的整數來作換算。
假設一個廚師平均2分鐘作完一道菜，那麼8個廚師2分鐘完成8道菜，換算一下就是4道/分鐘。
若是以分鐘爲單位進行統計，那麼這個數字就是最終結果。
每秒事務數（TPS）：
通常應用服務器的處理速度跟廚師作菜是不在一個數量級的，常見的事務請求在應用服務器端的處理時間以毫秒爲單位計算。
因此測試性能時，咱們更經常使用「1秒鐘」來做爲切片時間段。
一秒鐘完成多少個事務請求，這個數據就是咱們耳熟能詳的「每秒事務數」。
這個指標翻譯成英文就是TPS - Transaction Per Seconds。（也有用QPS - Query Per Seconds來統計的，其差別暫時不作討論了）
每秒事務數，就是衡量服務器性能的最重要也是最直觀指標。
每秒能完成的事務數越多，那麼每分鐘能完成的事務就越多，天天完成的事務數就越多 -- 簡單的小學數學。
那麼他直接能影響到一個應用服務天天平均能承受的訪問量/請求量，以及業務高峯期能承受的壓力。
平均響應時間：
那麼有哪些因素會影響到TPS數值？
有兩個主要的維度：
- 單個事務響應速度
- 同一時間能並行執行的事務
第二點咱們說了，它主要跟服務器資源配置，線程池容量，線程調度等相關。
第一點換一個說法就是：事務平均響應時間。單個事務平均下來完成的速度越快，那麼單位時間內能完成的事務數就越多，TPS就越高 -- 簡單的小學數學。
因此在進行性能調優時，除了服務器容量資源，單個事務響應速度是另外一個關注的重點。
要關注事務響應速度/時間，能夠考慮在事務內部邏輯節點添加「耗時探針」的方式，來探測每一個步驟分別花費的時間，從而找出可優化的部分。
吞吐量
吞吐量是在性能探測過程當中常常冒出來的名詞，怎麼理解他呢？
簡單的結論就是，吞吐量是站在「量」的角度去度量，是一個參考指標。
可是光有「量」的數據有時候並沒有太大價值，一家餐廳1個小時賣出100份餐品和一個月才賣出100份餐品，單從「量」的維度衡量確定不行，時間維度很重要！
因此，性能測試領域的吞吐量一般會結合上時間維度進行統計。
若是吞吐量的「量」以「事務」爲統計單位的話，結合時間維度，轉化之後能夠很容換算成TPS。
4. 最後，關於性能測試的一些碎碎念
測試類型
因爲測試目標的不一樣，性能測試可能存在不少種形式。
好比明確瞭解日訪問量和巔峯訪問量，測試服務器是否可以承受響應壓力的測試。
好比用於探測系統負載極限和性能拐點的測試。
好比衡量系統在高負載狀況下，長時間運行是否穩定的測試。
這許多種形式咱們暫且不作討論，不過全部以上測試的基礎都是它 -- 「併發測試」。
製造併發，是性能測試的基本實現辦法。
進一步細化理解客戶端線程數和併發量的關係
設服務器併發能力爲每秒完成1個事務，即TPS=1/s。且服務器使用單核處理器，現用Jmeter啓動5個線程循環進行併發測試，那麼每一個切片時間（每秒）都發生了什麼？
咱們能夠用以下圖表來分析：
其中，爲線程可執行（等待執行），爲線程正在執行，表示線程執行完畢。
假設其餘條件不變，增長服務器並行處理數爲2（增長CPU核數爲2，以及合理的線程調度機制）那麼變爲：
這裏真實的併發數（服務器單位時間完成的事務數）就是圖中每一秒鐘完成的事務數。
而客戶端啓動的其餘未處理的線程則在「排隊等待」。
線程併發數量
那麼製造多少併發，換言之，我應該用多少併發線程數去進行測試？
實際上客戶端發起的線程數與服務器可達到的併發數並沒有直接關係，但你應該使用足夠的線程數，讓服務器達到事務飽和。
如何判斷服務器是否達到飽和？這時咱們能夠採起階梯增壓的方式，不斷加大客戶端線程數量，直到服務器處理不過來，事務頻繁超時，這時就獲得了服務器處理能力極限。
根據不一樣的測試類型，取這個極限數量的必定百分比做爲客戶端線程數。
好比說，負載測試中，一般取達到這個極限數值的70%。
客戶端損耗
咱們在討論餐廳訂單流程和服務器事務流程時，流程圖裏包括了顧客/客戶端。
顧客點餐要不要花時間？固然要，若是他患上選擇困難症，甚至有可能在下單的時候花去大量時間。
同理，客戶端從啓動線程到構造請求併發出，這一過程也有必定的時間損耗。
一般在測試服務器性能的時候，客戶端性能是應該被剝離出去的，因此測試時應該儘可能下降客戶端時間損耗。
- 適當增長客戶端線程循環次數 - 稀釋這些線程啓動的佔用時間
- 當客戶端線程數須要較大數量時（對jmeter而言，超過1000左右），客戶機/測試機的資源佔用會增大，整個客戶端的請求構造時間會拉長。應該考慮分佈式測試。
- 儘可能減小客戶端請求構造時間，好比beanshell請求加密，若是過程過於複雜也會耗去可觀時間。極限測試狀況下應考慮簡化。
那麼本文到這裏告一段落。
但願能幫助理解性能測試領域的這些關鍵概念和原理。