我們經常需要對程序進行壓測，怎么壓才合適？壓到什么樣才說明應用達到了性能瓶頸？用什么指標來衡量才合適？一些指標異常又說明了什么？我們又該怎么樣去查問題？這些都是壓測時我們需要關注的。
按照大項劃分，個人將性能指標分為下面幾個大項：
一、基本性能指標 QPS 和 RT
這是測試過程中最基本的指標，也是我們主要需要關注的兩項。QPS 是指系統每秒處理的請求個數（query per second）。RT 指一個請求發出后系統的響應時間（reaction time）。區別下 QPS 和 TPS（Transactions per Second），他倆很像但是不是一個東西。TPS 是指每秒處理的事務數，一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。舉個例子比如某個接口里面有很多項操作，這時往往用 QPS 是不準確的，因為準確來說 QPS 針對的是 Query，是詢問，如單獨的數據庫讀甚至是寫都可以叫一個詢問，但當接口里有多個操作，本質上調用一次產生一次事務，同時里面有許多 Query。所以 QPS 往往會比 TPS 大些。如果針對應用來說我們調用一次內部邏輯又不可見不知道里面有多少操作，這時 TPS 和 QPS 常常區分不開的，建議用 TPS 來衡量好些。
這里還要提到一個重要概念：最佳線程數量，是指剛好消耗完服務器瓶頸資源的臨界線程數。 最佳線程數和 QPS、RT 是有一定關系的，這個線程數需要在壓測過程中不斷地去調整（一般從小到大來調，剛開始可能10個），努力去接近我們設定預期的性能測試極限。這個線程數和請求量正比關系，但是一定不要認為線程數少請求量就小。一般線程數設置8-10個左右，QPS 就可以達到 500 多了。舉個例子，一個線程一秒內可以發送 N 個請求其實也是固定的，那增加我們的線程個數，比如現在我們有 M 個線程，那每秒理論上可以發 M*N 個請求，不考慮應用瓶頸，那應用每秒 QPS 就可以達到 M*N，當然有瓶頸情況下 QPS 到一定程度就不會再提升了，因為一個應用每秒能處理的請求就那么多，每處理一個請求響應時間 RT 是有限的，當不斷請求過來產生堆積，響應時間上升了，還會導致 QPS 的下降。
先看看這三者的關系，QPS = 1000*線程數量/RT。QPS 單位是秒，RT 單位是毫秒，所以有一個單位換算分子乘以了1000。QPS 和 RT 成反比，當超過最佳線程數，會導致資源競爭加劇，同時響應時間也會增加，QPS 下降。
那么問題來了，如何找到最佳線程數？最土但是最實用的方法是，逐步壓測，不斷地調整線程數來觀察系統的負載。
二、數據庫指標
很多應用的瓶頸是在數據庫指標。比如連接數、數據庫的操作監控等等。
三、性能指標
性能指標是針對性能機器的，最佳線程數調整的監控項就是根據這個指標來的。這底下有很多東西，羅列一下：CPU使用率、JVM堆棧使用情況、GC/FGC 次數、Load指標、網絡延時。
3.1 CPU 使用率
一般性能測試指標，CPU 使用率小于 75% 比較合適。通過指令：cat /proc/stat 可以查看。第一行CPU是所有CPU數據總和，CPU0~3表示各個CPU數據。其中第一列為從系統啟動開始累計到當前時間，用戶態的CPU時間（單位：jiffies，1 jiffies = 0.01秒）。
3.2 JVM 堆棧使用情況
對于我們的應用來說，一般會配置 JVM 的，所以對于應用來說，看機器的整體內存是沒有意義的，我們更要關注的是堆棧的使用情況，關注點在已用堆信息。
3.3 GC / FGC 次數
在性能測試過程中不能出現因為FGC 的產生導致響應時間急劇升高的現象，否則壓測是不正確的。盡量保證 FGC 的出現次數是0，如果出現看看它的運行時間，要確保是 FGC 產生運行時間足夠短，否則就可以提Bug了。GC 產生是比較正常的，也要確保它的產生時間保持在比較低的水平。
3.4 Load 指標
Load 是 CPU 的負載，它所包含的信息不是 CPU 的使用率狀況，二是在一段時間內 CPU 正在處理以及等待CPU處理的進程數之和的統計信息，也就是CPU使用隊列的長度的統計信息。一般測試時它的指標是Load<CPU的核數*2。通過指令：cat /proc/loadavg 可以查看。五個數字分別是一分鐘平均負載，5分鐘內平均負載，15分鐘內平均負載，采樣時刻運行隊列的任務數目，系統中活躍任務數目，最大 pid 值（包括線程）。
3.5 網絡延時
常用應用服務器ping數據庫，看看數據庫延時是多少。
四、整體測試指標
RT（Response Time）<= 200ms，根據業務有所不同，只讀的可能小于 10ms。
Load 服務器負載 <= CPU Core
CPU <= 75%
壓測失敗率 <= 0.2%
此外還要關注下方法耗時。
五、工具
Visual VM
