一、性能測試中的TPS

眾所周知，TPS(即Transactions Per Second的縮寫)是性能測試中的一項重要指標，用于衡量被測系統的性能，TPS高則說明系統處理速度快，TPS低則說明系統處理速度慢，可能需要做性能優化。通常TPS只是反應測試結果，測試出多少就是多少，然而很多時候我們需要事先指定TPS的目標值，通過測試來驗證目標值是否達，那么該如何進行測試呢?

二、基于目標的性能測試

Loadrunner在新建測試場景時，就可以選擇手動場景還是基于目標的場景，如下圖所示：

目標類型可以選擇tps、hits per second等：

設置好目標后，直接運行就可以了，執行完成可以看到目標是否達到了。這個過程都是自動完成的，其內部是如何實現的，對于我們來說完全是個黑盒子。本文介紹的是如何通過手動設置場景來完成基于TPS目標的測試，重點介紹目標TPS是如何計算出來的。

三、測試場景的設置

我們還是選擇手動設置loadrunner的測試場景，通常會有單交易場景測試和混合交易場景測試，下面是2個示例：

無論是單場景還是混合場景，目標TPS的計算原理都是一樣的。

四、場景公式

在上面的場景例子中，我們需要重點關注4個字段：

• 虛擬用戶數量(簡稱vu)
• 目標tps
• Pacing
• Thinktime

所有場景的 thinktime 都是 0 秒，pacing 和 thinktime 在概念上有聯系也有區別。

Thinktime 比較常用，易理解，這里不多介紹，下面重點說一下 pacing。Pacing 是 loadrunner中的一個設置選項，如下圖所示：

Pacing 指 action 迭代的延遲時間，選項一是迭代不延遲，選項二是在上一次迭代結束后多長時間開始下一次迭代，選項三是每次迭代從開始到結束的時間間隔。

選項三實際上是設置每次迭代的期望完成時間，例如設置pacing為60秒，表示action這個事務要求在60秒內執行完成，如果action執行了4秒，那么后面的56秒會等待，直到60秒后再開始下一次迭代;如果action執行了120秒，那么執行結束后會立即開始下一次迭代。前者我們可以稱之為“包含住”，因為執行時間小于pacing時間，后者稱為“未包含住”，因為執行時間大于pacing時間。只要action的平均響應時間“包含住”了，目標TPS就可以達到。

理解上面的原理很重要，下面我們看一個例子。

假設有如下的測試結果：

vu為1時action的響應時間只要小于等于2秒pacing，理論tps應該都是0.5，換句話說只要action響應時間在pacing內，響應時間再快，tps不會增加。

vu為 10 時，action的響應時間仍小于2秒，在pacing范圍內，“包含住”了，達到5個TPS。同理，vu為20時，action的響應時間仍小于2秒，在pacing范圍內，“包含住”了，達到10 個TPS。在action的響應時間未超出pacing之前，tps和vu存在正比關系。

vu為100時，action響應時間為10秒，不在pacing2秒范圍內，“未包含住”，理論的50個tps就不可能達到了。

通過以上分析，我們可以得出vu、pacing、目標tps三者之間的關系，即：

在action的響應時間未超出pacing之前，目標tps=vu/pacing通過該公式，可以較精確的測試出系統的tps，通過大量的測試試驗，結果也是和公式吻合的。

目標tps根據需求得到，設置一個pacing就知道需要測試多少vu。減少pacing和增加vu都可以增加目標tps。建議的做法是先設定pacing，然后再設置vu，pacing的取值基本都是10秒，或者是10秒的倍數。pacing確定后就不再改變，要想增加目標tps，只能調大vu。

五、總結

本文介紹了基于目標tps的性能測試方法，希望通過本文，能讓大家對tps的設置有更深入的了解，在做性能測試時做到目標清晰，有章可循。