2012-04-21 128 views
28

我開始在JMeter中編寫一些基本測試,並且感到驚訝的是測量結果與Apache ab中的測量結果差別很大。JMeter或Apache ab可以獲得正確的測量結果嗎?

我有一個千兆局域網連接運行Nginx的英特爾i7服務器和運行JMeter或ab的i5測試機器。最初,我只是測試開箱即用的Nginx主頁響應率。

ab -c 1 -n 100 http://testserver.local/ 

Document Path:  /
Document Length:  151 bytes 

Concurrency Level:  1 
Time taken for tests: 0.078 seconds 
Complete requests:  100 
Failed requests:  0 
Write errors:   0 
Total transferred:  38400 bytes 
HTML transferred:  15100 bytes 
Requests per second: 1280.77 [#/sec] (mean) 
Time per request:  0.781 [ms] (mean) 
Time per request:  0.781 [ms] (mean, across all concurrent requests) 
Transfer rate:   480.29 [Kbytes/sec] received 

這個結果是一致地重現,+/-百分之幾。


在JMeter的,我具有包含1-用戶100環線程組:

  • HTTP頭管理器設置的Accept-Encoding:gzip的
  • 一個HTTP GET /採樣
  • 總結報告收聽者

只有100個樣本,每次運行結果都不一致。但最令人吃驚的事實是吞吐量低至每秒40個請求(不是1280個)。最高的記錄率是1030,這隻有當我增加到10000個樣本時才能達到。

我是否認爲JMeter是簡單負載測試的錯誤工具,因爲它的開銷太高,無法進行準確的測量?

+1

+1,但我認爲你的結論是正確的。 – 2012-04-21 15:58:02

回答

48

Jmeter告訴你多久每個請求實際上了。 AB只是做一些非常基本的數學來獲得整體平均值。所以,對你的問題的直接回答是,jmeter能夠正確地做出決定,而且只是通過給你所有的意思來粗略猜測。

但是,當然,如果您將兩個工具並排放置並對速度進行評分,那麼ab顯然會超出jmeter。 Jmeter做得更多,它記錄更多的數據並且處理更多的邏輯,因此需要更長的時間才能完成單個請求。簡單的事實是,Jmeter是一個全功能的負載測試工具,AB不是。

的事情是,一個負載測試工具的目的不是要塊上最快的孩子,取而代之的則是對能夠建立排序的真實表示加載的應用程序可能會被擊中當它變爲現實時。在這方面,jmeter勝手,所以這取決於你的要求。如果你只是想用盡可能少的硬件來生成儘可能多的請求,那麼ab是一個不錯的選擇,但是如果你想要建立一個有代表性的測試,使用事務旅程,條件邏輯和其他各種有用的東西,那麼jmeter就是要走的路。可以這樣想:它們都是Apache項目,但我認爲AB是爲了測試Apache Web服務器JMeter而設計的,目的是測試Tomcat。

現在,我猜測jmeter產生不一致的結果,因爲它正在運行的機器上達到限制。我敢打賭,你在GUI模式下運行,並且至少有一個監聽器處於活動狀態,就像你要求該工具做了很多事情一樣。如果你需要很高的請求率,那麼Jmeter就有一個精簡和平均模式。通常情況下,對於大容量來說,最好的做法是在命令行上用很少的聽衆執行測試;有很多關於這個主題的信息在apache jmeter網站上。

另一點你應該考慮,如果你真的進入負載測試,是爲了真正從這種事情中受益,你需要首先決定什麼樣的負載,你需要你的網站支持,只有那麼你應該設計一個代表這個的測試。這是通過使用起搏和模擬等待時間來實現的。以講述一個線程是應該走開,並以最快的速度,因爲它可能可以運行的問題是,作爲當地條件允許的話它會快速迭代,但會有總是是東西,穿的休息,甚至ab是有限的;無論多麼輕巧的工具,它仍然有東西。但是,如果您對請求進行排序,那麼您將消除此問題並作爲一個相當有用的額外獎勵,從而最終實現運行之間以及代碼構建之間的一致性,因此即使您的服務器加速或減速(通過更改代碼庫)你的測試仍然會產生相同的請求率 - 這對基準測試非常有用。

如果你想利用JMeter的進一步再看看恆吞吐量計時器,然後使用多線程建立交通的需要來表示的水平。

+0

ApacheBench(我同意「基本數學」)可能會產生較少的數據,但這意味着它無法正確計算平均值。 OP使用'ab'平均每秒報告1280個請求。他從JMeter報告的最高是1030.儘管我同意你列出的關於JMeter的各種好處,但我不能忽視JMeter不像ApacheBench那樣讓Web服務器飽和的明顯事實。出於這個原因,我發現你的斷言「jmeter正確」可疑。如果JMeter說得對,它應該至少產生一個可比較的平均值。 – 2016-01-10 06:07:01

+0

嘿湯姆,實際上我從來沒有說過從ab的意思是不正確的,只是它只是數學的意思,而不是像JMeter給出的結果的更詳細的分解。回覆。關於誰可以每秒產生最多請求的其他觀點,我可以參考我關於該區塊中速度最快的孩子的第3段,但基本上OP是混淆的,因爲他沒有考慮到他的測試硬件限制。謝謝。奧利弗 – 2016-01-11 10:22:08

3

在你的設置,JMeter是速度比它可以飽和你的Web服務器本身飽和。對較小的硬件相對較重的Java應用程序

您正在運行優越的硬件和一個非常優化的C Web服務器基準標記它。優化後的C機器代碼將(可能)總是比Java字節代碼更快。 JMeter無法跟上Nginx的步伐,因此會給你帶來奇怪的結果,因爲它遇到硬件限制。 Java在後臺管理硬件資源方面做了很多很棒的事情,但在極端的資源使用情況下也會產生不可預知的行爲。另一方面,ApacheBench是一個輕量級的C程序,它可以使服務器達到飽和,並且可以產生一致的結果,因爲在飽和Web服務器之後它具有過剩容量。

JMeter是非常適合那些需要一些時間來處理請求基準標記重-ER動態應用。它提供的所有額外數據都可以幫助像這樣的網絡應用程序。當您在高度優化的Web服務器上處理靜態文件服務(僅僅是Web服務器可以做的最快的事情)時,您需要足夠快的工具來跟上。

0

正如第一個答案中所述,關鍵字「要求」。 JMeter是測試服務器網頁的更好選擇。例如,它可以發送請求序列,爲每個序列生成不同的請求,解析HTML響應並從HTML中加載圖像和腳本的內容。 AB是對REST API的測試,你需要的是服務器響應儘可能地快,併成爲許多要求儘可能更好的選擇,在兩個序貫要求等之間沒有連接 所以,AB確實能夠產生比JMeter和同一臺客戶機上的同一臺服務器有更多的請求。

相關問題