經常在系統的需求書當中看到這樣的描述“響應時間在3秒以內”，這類需求讓測試人員無從下手，這是在多大的並發用戶數下面得到這個結果？在多少存量數據的情況下得到這個結果？ 1年、2年？即使隨便設置個場景測完了，也不敢出具測試結論。

業務指標是從用戶操作的角度體現出來的，相對於服務指標。服務指標是從系統對外提供服務的角度設定的指標。主要指標有業務類型、業務配比、並發用戶數。

在描述一個系統的性能表現時，我們常常采用三段式的表達方法：業務指標-資源指標-服務指標。

例如：在處理典型業務AAA與典型業務BBB、二者業務配比為1:3時，當CPU（10C）利用率達到70%時，系統的吞吐量為每秒200筆交易，交易響應時間為80毫秒。

只有這“業務指標-資源指標-服務指標”三段論都說齊了，才算一個“相對”可參考的性能結論。之所以稱之為“相對”是因為，隨便改一個參數都可能對性能造成巨大的影響，任何性能結論都是在審慎的態度下給出的。

一、業務類型

業務的種類、名稱。

不同業務種類的處理邏輯、處理效率不一樣，因此需要明確業務類型。

二、業務配比

不同業務在同一個場景中時，單位時間內數量的比例。

三、並發用戶數

在詳細解釋並發用戶數之前，可能需要分辨一下雙方討論的並發數是“並發用戶數”？還是系統並發數？還是在系統中註冊的用戶數？還是在線用戶數？

我們知道，已登錄的用戶不一定有操作。

並發用戶數的確定必須和業務場景相結合。需要明確是哪個模塊的系統並發數，登陸模塊？查詢模塊？下載模板？這些都是不一樣的。如果要看混合場景，需給不同模塊操作的用戶配比。具體但單個模塊的場景，需給出用戶的發起頻率（這個後面還會介紹），比如5分鐘操作一次，還是10秒鐘操作一次。

為什麽並發用戶數是一個重要的性能指標？

最重要的原因是並發用戶的數量直接影響了用戶自身的體驗。任何對系統性能的分析、測試、調優都是以用戶為圓心的。當並發數多了的時候，用戶感受到的響應時間可能會變長甚至服務中斷。原因如下：

當每個用戶在服務器端都會有一個進程/線程來提供服務，當並發的用戶多了之後，進程/線程的調度開銷，CPU上下文切換增多，會影響執行效率。

當並發的用戶多了之後，由於程序的設計原因，可能會多個用戶競爭同一個資源，由此產生內存栓鎖、數據庫鎖、信號量等等控制競爭的機制，從用戶的角度看到了排隊。

同時，系統中有最大連接/最大session/最大線程數量的限制。當達到最大值後，更多的用戶請求不能接待，產生等待或報錯。這些最大值的限制，有些是人工設置的結果（例如最大連接/最大session數），有些是系統自身計算的結果（例如最大線程數）。

對於人工設置的最大值是可以調節的，有時調大會起到不錯的效果，但並不是所有情況下調大都有正面的作用。人工設置最大值和系統自身計算最大值本質上是一樣的，即系統的資源是有限的，總會有一個天花板。

以Linux為例，最大線程數是多少是根據系統物理內存數量來計算的（有興趣可以翻看Linux內核源代碼），因為每個線程要開辟一塊內存區域給這個線程。

有時並發用戶數越少，性能反而越差

這種情況出現在用戶自己等自己的情況，歸根結底還是資源的競爭。

舉例：當系統整體吞吐量相同的時候（每秒10000筆交易），每筆交易修改自身的數據庫中的某一個表的固定的一行（例如：賬戶余額）。

1）100個並發用戶，每個用戶每秒100筆交易，那麽每個數據庫的行鎖每秒需要鎖定100次。

2）10個並發用戶，每個用戶每秒1000筆交易，那麽每個數據庫的行鎖每秒需要鎖定1000次，即所謂的熱點賬戶問題。

四、存量數據

在數據庫或文件系統中，用戶已經存儲了多少業務數據，比如1年或1000萬條等等表達方式。

存量數據對用戶的增刪改查性能有非常明顯的影響，在數據庫中體現更明顯。10個數字當中找一個，和10億個數字當中找一個難度自然不同。

五、發起頻率

這個指標很少有人關心，但的確對系統性能有些影響。

5.1 相同吞吐量下不同的發起頻率

舉個例子，一秒發起100筆報文，可以有不同的發起頻率：

1） 每10毫秒發起1筆報文

2） 每100毫秒發起10筆報文

3） 每1000毫秒發起100筆報文

這三種發起頻率下，系統的吞吐量都是每秒100筆報文，但是系統資源利用率、響應時間等指標會略有差異。

試想，火車站有一個售票窗口，如果每隔1分鐘來一位旅客，那麽每位旅客的等待時間就非常短。而如果每小時的整點一次性來60位旅客，那麽旅客的平均等待時間就比較長。

在計算機系統中，到底哪種發起頻率會響應時間短，與系統的設計有關。假設應用程序設計為，“每湊齊10筆報文讀取並處理一次“，那麽采用頻率1似乎等待的時間更長。有人會問，會有這種邏輯設計嗎，其實在系統性能調優的時候，經常有這樣的批量處理原則；比如從MQ隊列中每次讀取10個報文，MQ每10筆commit一次，SQL語句每10筆commit一次，網絡中的delayACK（湊齊一個window的數據包再一次性回復ACK）。

上面說到了對響應時間的影響，其實發起頻率對系統資源消耗也同樣存在影響。頻率1中，系統只啟動一個進程就可以處理，而頻率3中，一次性達到100筆報文，應用讀取中間件隊列的深度後發現一次性的來了100個報文，則決定啟動20個進程並發處理，很快處理完成後，這些進程基本都被銷毀，只留下1個值班的進程。那麽在這個大量創建進程、銷毀進程的過程中，CPU消耗是非常大的。

總之，在計算機系統中，到底哪種發起頻率會響應時間短，系統消耗少，是與系統的設計有關，不能一概而論，唯有實測才最準確。

5.2 不同吞吐量下不同的發起頻率

這個概念比較好理解，一個用戶每分鐘發起1次請求和10次請求，那麽這個用戶的發起頻率是不同的，同時也影響了吞吐量的不同。

對於頁面形式的性能測試，在需求書中經常可以看到如下的需求：

“在並發用戶數為100的時候，響應時間為3秒以內”

從業務指標的角度，這裏缺少了一個要素，就是用戶發起頻率。每個用戶是每秒發起1次請求還是10次請求？

如果不描述這個發起頻率，則需要從系統的角度補充吞吐量指標。

關註發起頻率的另一個目的是驗證服務端是否達到了吞吐量極限。

系統的吞吐量沒有達到預想的數值，需要首先分析：

1） 是用戶沒有發出來這麽大壓力？

2） 用戶壓力足夠，但系統不能完全處理

因此，發起頻率不但要關註，並且要可以穩定的壓出。這一部分內容會在後續測試工具的章節介紹。

轉：性能指標之業務指標