的JMeter：吞吐量和KB /秒

我具有15個線程，每個發送一個32KB圖像（HTTP POST）線程組之間的相關性的理解。在總結報告中，我的吞吐量爲550 /秒，平均響應時間爲25毫秒，KB /秒爲148KB /秒。我發現難以關聯這些數字。如果我可以管理550請求/秒，每個請求是32KB，不應該KB /秒是550 * 32 KB /秒？的JMeter：吞吐量和KB /秒

編輯： 即使我只發送一個請求，KB /秒下的數字是沒有意義的。我能夠關聯所有其他數字。 1請求的總結報告：

Samples: 1 
Average: 25 
Min: 25 
Max: 25 
Std.Dev: 0 
Error: 0% 
Throughput: 40/sec 
KB/Sec: 10.62 
Avg. Bytes: 272.

從上述結果很容易關聯平均時間和吞吐量。我傳輸的圖像大小爲32281字節（由linux操作系統報告）。正如在評論中指出的那樣，我懷疑這是否需要對壓縮做任何事情。我試圖發送一個1MB的圖像，KB/Sec的報告是12.3。

來源

2012-04-10 Prasanna

您如何測量550 /秒請求速率？ – aroth 2012-04-10 01:19:00

是總結報告中的Jmeter在吞吐量欄下報告的東西。 – Prasanna 2012-04-10 01:47:51

所有我能找到的文獻似乎表明在每分鐘的請求，每秒不要求是JMeter的報告吞吐量。每分鐘550個請求大致位於您的其他數字可預期的範圍內（實際上，每分鐘達到550次上傳的平均速度大約爲300 KB /秒，但是也許每秒鐘的速度爲148 KB /秒瞬時讀數，或也許有被施加到32 KB圖象某些壓縮，或也許是32 KB圖象實際上是略小於32 KB，等）。 – aroth 2012-04-10 02:00:09

在1個請求示例中的數學看起來正確的給我。

Samples: 1 
Average: 25 
Min: 25 
Max: 25 
Std.Dev: 0 
Error: 0% 
Throughput: 40/sec 
KB/Sec: 10.62 
Avg. Bytes: 272.

按照您數據以上，40個請求第二，在平均272個字節=（40 * 272）10880個字節的第二吞吐量（當由1024劃分爲10.625）。

問題肯定是剛纔爲什麼JMeter的認爲平均請求大小272bytes，你認爲這是32K - 你確定圖像被附？如果是這樣，我會認爲有一些相當大的壓縮正在進行。

來源

2012-04-10 19:44:24 rhinds

是的，我也注意到了，但後來才發現平均值。字節是響應的大小，而不是請求。所以KB/Sec實際上是響應吞吐量（也就是服務器吞吐量）。我通過這個做了一個tcpdump的確認。 – Prasanna 2012-04-10 21:03:55

這帶來了一個重要問題，我們如何衡量服務器接受用戶生成數據的能力？ – 2013-10-09 04:35:26

的JMeter：吞吐量和KB /秒

回答

相關問題