JMeter性能測試——利特爾定律在工作負載模型中的應用

利特爾定律（Little’s law）應該是最著名的排隊理論之一！讓我們看看如何將其用於性能測試。

利特爾定律(Little’s law)

穩定系統中的長期平均客戶數(N)，等於長期平均有效抵達率(λ) 乘以客戶在系統中平均花費的時間(W)；可以用代數表達式表示爲：N =λW。

利特爾定律是普遍適用的，它可以應用於存在隊列的任何地方，從零售商店到CPU /應用服務器。
假設售票櫃檯中用戶平均花費15分鐘（W），客戶以每小時20個客戶的速度抵達（λ），假設每個人都買票。

使用利特爾定律，我們可以隨時計算系統中的平均客戶數爲N =λW
λ = 20 /Hour
W = 15 min= 0.25 Hour
因此，N爲5 =(0.25 * 20)

雖然我們可以預期每小時有20個客戶，但由於客戶在櫃檯上僅花費15分鐘，所以系統中只有5個客戶；隊列中有4個，正在維護1個。

抵達率：

客戶進入系統的速率稱爲抵達率。

退出率：

客戶離開系統的速率稱爲退出率。

利特爾定律假設系統穩定，因此到達率和離開率相同。

性能測試中的利特爾定律：

利特爾定律也可以應用於我們的Web /APP/數據庫服務器，以關聯用戶/請求總數，服務器的吞吐量(TP)和平均響應時間。

吞吐量 ––是每單位時間處理的請求數；可以用作退出率（λ）。

響應時間 ––平均響應時間是請求在系統（W）中花費的時間。它包括等待時間+服務時間。

N = 吞吐量 * 響應時間
(N = Throughput * Response Time)

思考時間會影響系統吞吐量。因此，如果有任何思考時間，

N = 吞吐量 *（響應時間+思考時間）

性能測試結果驗證：

讓我們看幾個例子，以理解爲何利特爾定律可以用來驗證我們的性能測試執行結果。

• 在我們的tomcat服務器中，在server.xml中更新線程池中的最大線程數只能處理10個併發，如果超過10，它將排隊等待。讓我們看看在這裏如何應用利特爾定律。
• 我還想控制響應時間，更新tomcat示例中的hello.jsp文件，添加了一個顯示等待2000毫秒–tomcat需要2秒來處理此請求並做出響應。

現在我們知道訪問該頁面的每個請求將需要2秒鐘的時間來處理，我們也知道池中只有10個線程。
因此，tomcat可以在2秒內處理10個請求，我們將tomcat的服務器吞吐量限制爲(10/2 =) 5個請求/秒。

• 我創建了一個包含10個併發用戶的簡單測試來訪問該頁面，進行了一段時間的測試。
  
  根據上述JMeter的彙總結果：
  平均響應時間（W）爲2009毫秒
  吞吐量（λ）爲5 /秒
  因此，系統中的用戶數N

   N =  吞吐量 * 響應時間
   N = 5 * 2.009
   N = 10.045，非常接近10
  

• 這次，我對50個 併發用戶進行了相同的測試，得到以下結果：
  

   W = 9.742秒
   λ = 5 /秒
   N = 9.742 * 5 = 48.71 ，接近50
  

這證實了響應時間與用戶負載是同步的。如上所示，可以使用利特爾定律來驗證你的性能測試結果是否準確。

工作負載模式：

工作負載模式是由給定併發用戶在給定時間內執行的一組業務事務，用於分析被測試系統的行爲。
工作負載模式在性能測試中非常重要，如果它不能反映最終用戶的模式，那麼你的性能測試結果就是浪費!

我們不能創建一個簡單的性能測試計劃，該計劃隨機地考慮用戶的數量，並具有任意思考時間！
爲了找到合適的工作負載模式，您至少需要提供以下信息：

• 關鍵業務交易
• VUsers的數量
• 操作用戶的百分比
• 思考時間
• 期望吞吐量

通常，上述信息應該由客戶/業務分析師等提供；但有時作爲一個性能測試工程師，可能會遇到一個問題：即客戶對非功能性需求一無所知。然而他們希望進行性能測試；讓我們看看如何在Google-analytics工具的幫助下利用利特爾定律來得出一個工作負載模式。
谷歌分析工具可以爲我們提供經常訪問的頁面，對於處理涉及這些頁面和某個操作的用戶百分比的業務工作流來說，這是一個很好的信息。

吞吐量計算：

對於其中一個應用程序，google-analytics顯示的是一年中某一天的峯值信息。

• 20071個用戶登錄
• 277576次頁面瀏覽
  從頁面視圖中，我們可以計算服務器的吞吐量。
  也就是說，如果服務器每天處理277576頁，那麼它每秒將處理3.2個頁面請求。（277576 /（24 * 60 * 60））

但這是不對的！
Google Analytics還提供當天的網頁瀏覽量分佈，在高峯時段，我們的服務器在一小時內處理了34435個頁面。

因此，我們可以將此峯值小時數用於期望的吞吐量計算。34435 /（60 * 60）給出9.56頁/秒，這應該是期望的吞吐量。

思考時間計算：

從上圖中可以看出，一個用戶會話持續了9分15秒，即555秒。

在會話期間，用戶瀏覽8.78個頁面。

兩次頁面查看之間的時間間隔爲555 / 8.78 = 63秒

響應時間+思考時間= 63秒

如果我們知道響應時間，我們就可以相應地調整思考時間。

用戶總數計算：

Google Analytics還顯示，在高峯時段，我們有大約3904位用戶。

事實上，這並不意味着你需要使用3904個併發用戶運行負載測試。因爲它是一個小時的彙總信息。

根據利特爾定律，用戶總數N =吞吐量（響應時間+思考時間）*

	N = 9.56 * 63
	N = 602位用戶

602個併發用戶足以運行負載測試。

也就是說，通過設計一個持續9分鐘15秒、602個用戶的測試計劃，您將擁有3910個用戶登錄，這與我們當前的生產工作負載非常接近。

總結：

一些性能測試人員可能知道如何使用JMeter / LoadRunner 或者其他工具制定測試計劃，並且是他們認爲無論得到什麼結果都是準確的。然而事與願違！
例如：您的系統資源可能非常有限–如果您對1000個併發用戶運行JMeter測試，JMeter會給出一些結果；永遠不要假設結果是正確的，要不斷的使用利特爾定律交叉覈對你的結果，根據JMeter的結果，假設說吞吐量爲50 /秒和平均響應時間（包括思考時間）爲13秒。

	N = 50 * 13

	N = 650

	我們的預期N應該是1000左右。所以這裏出了問題！！

因此，可以使用利特爾定律來確保觀察到的性能結果是不是由於我們的負載生成工具造成的瓶頸。