最近在寫一些東西的時候，把一些內容整理了一下。
在考慮壓力工具中的使用者數（有些工具中稱為執行緒數，本文後續都用“使用者數”來說明）、響應時間、TPS三者之間的關係時，想到之前也有人問起過這樣的問題，就是他們三者之間的共生的關係到底是什麼樣呢。
這個公式我想誰都能知道了：
TPS = （ 1 / RT ) * user (其中，RT單位是秒，user是使用者數)
先來畫一下最簡單的圖（假設前提：每個user的事務定義都是一致的。）：
當有五個使用者時，響應時間都穩定保持在0.2s，那這個場景的TPS顯然是：
TPS = （1/0.2)*5 = 25
這是最簡單的計算了。
（也許你會說：“咳，不對，因為線畫歪了！”
你過來，我保證揍不死你。）
這個看似簡單的公式，在實際的場景中卻是會出現千奇百怪的結果。因為大部分的場景都不會如此規整，例如：
這種情況下怎麼計算TPS呢：
TPS = 2 + 4 + 6 + 4 + 1 = 17
顯然響應時間也是變化較大的，可能每個使用者的每個事務的響應時間都是不一樣的。
在真實的場景中，這樣的情況是必然會出現的，所以在計算TPS的時候，壓力工具採用的是：
-
先採集原始資料。即每個使用者每個事務都記錄下來。
-
再根據粒度計算。TPS散點值 = 事務數 / 粒度
這樣的計算結果再通過曲線表現出來。就會受幾個因素的影響：使用者數、粒度、響應時間。
當粒度過大時，就會平均掉毛刺的影響；當粒度過小時，就會產生過多的事務點，讓人抓狂。
那到底什麼樣的TPS和響應時間是讓人滿意的呢？像這樣嗎？
響應時間隨使用者數上升而上升，TPS達到上限後變平；
這顯然不是讓人滿意的曲線，因為我們希望的是響應時間不要增加那麼快。
那這樣的曲線呢？
響應時間有增加，但是增加的趨勢並不快，TPS也一直有增加的趨勢，這就顯然系統還有容量的空間，就看效能指標該如何確定了。
我們多麼希望這三者的關係像這個圖呀。
響應時間從來沒有增加過，TPS一直在增加，系統效能在測試範圍內沒有衰減。
當然，這是不可能的。
通常情況下，我們都要面對更復雜點的場景。如下圖：
在這個非常簡單的場景下，我們也看到了響應時間無理的跳動。還好幅度並不大。所以才保證了TPS在每個不同的使用者梯度下相對的穩定。但是顯然後面TPS已經達到上限了，響應時間開始增加得非常快。
對於這樣的場景來說，已經算是非常清晰的使用者數、TPS、RT的關係了。
而對於一些這三者關係根本找不到的效能場景，首先要做的就是要把場景判斷清晰，讓曲線變得穩定，再判斷瓶頸，然後才是定位瓶頸及分析根本原因。
想讓曲線變得穩定，就涉及到場景的執行策略了。
遞增使用者和場景的連續性是一定要保證的，只是梯度要根據實際的情況來判斷。
今天先聊這麼多，以後碰到有人問類似的問題再接著聊。