哪个测量正确,JMeter或Apache ab?

Ric*_*777 38 benchmarking jmeter apachebench

我开始在JMeter中编写一些基本测试,并且惊讶于测量结果与Apache ab的测量结果非常不同.

我有一个千兆局域网连接运行Nginx的Intel i7服务器和运行JMeter或ab的i5测试机.最初,我只是测试开箱即用的Nginx主页响应率.

ab -c 1 -n 100 http://testserver.local/
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

该结果始终可重复,+/ - 百分之几.


在JMeter中,我有一个1用户的100循环线程组,其中包含:

  • HTTP头管理器设置Accept-Encoding:gzip
  • HTTP Get/sampler
  • 摘要报告监听器

只有100个样本,每次运行时都会产生非常不一致的结果.但最令人吃惊的事实是报告吞吐量低至每秒40个请求(而不是1280).最高记录率为1030,这仅在我增加到10,000个样本时才实现.

我是否认为JMeter是简单负载测试的错误工具,因为它的开销太高而无法进行精确测量?

Oli*_*oyd 61

Jmeter告诉你每个请求实际花了多长时间.AB只是做一些非常基本的数学计算来得到整体平均值.因此,对你的问题的直接回答是,jmeter正确,ab只是通过给出你所有的平均值来粗略猜测.

但是,当然,如果你并排放置这两个工具并对速度进行评级,那么很明显ab将会执行jmeter.Jmeter只是做得更多,它记录更多数据并处理更多逻辑,因此转换单个请求需要更长时间.简单的事实是Jmeter是一个功能齐全的负载测试工具,AB是,嗯,不是.

问题是,负载测试工具的目标不是成为块中速度最快的孩子,而是能够构建一个真实的表示,表明应用程序在上线时可能遇到的负载类型.在这方面,jmeter胜出,所以它实际上取决于你的要求.如果您只想使用最少量的硬件生成尽可能多的请求,那么ab是一个不错的选择,但如果您想构建具有代表性的测试,具有事务性旅程,条件逻辑和各种其他有用的东西,那么jmeter是要走的路.可以这样想:它们都是Apache项目,但我认为AB是为了测试apache web服务器而设计的,但JMeter是为测试Tomcat而设计的.

现在,我猜测jmeter正在产生不一致的结果,因为它在它运行的机器上达到了极限.我打赌你是在GUI模式下运行并且至少有一个监听器处于活动状态,这样你就要求该工具做很多事情.如果您需要高比率的请求,那么Jmeter具有精简和平均模式.通常,对于大容量,最佳实践是在命令行执行测试,只有很少的侦听器; 在apache jmeter网站上有很多关于这个主题的信息.

如果你真的进入负载测试,你应该考虑的另一点是,为了真正从这类事情中获益,你需要先确定你的网站需要支持哪种负载,然后才应该设计代表这一点的测试.这是通过使用调步和模拟等待时间来实现的.告诉线程的问题应该是尽可能快地消失并且运行速度尽可能快,它会以本地条件允许的速度迭代,但是总会有一些东西会打破,甚至ab是有限; 无论工具多么轻巧,它仍然可以做些什么.但是如果你调整了你的请求,那么你就可以解决这个问题,并且作为一个相当有用的额外奖励,你最终会得到运行之间和代码构建之间的一致性,所以即使你的服务器加速或减速(代码库的更改)您的测试仍然会产生相同的请求率 - 这对于基准测试非常有用.

如果您想进一步使用JMeter,请查看Constant Throughput Timer,然后使用多个线程来构建您需要表示的流量级别.

  • ApacheBench(我同意它只是做“基本数学”)可能会产生更少的数据,但这意味着它无法正确计算平均值。OP 报告使用“ab”平均每秒发出约 1280 个请求。他从 JMeter 报告的最高值是 1030。虽然我同意您列出的有关 JMeter 的各种好处,但我不能忽视一个明显的事实,即 JMeter 没有像 ApacheBench 那样使 Web 服务器饱和。因此,我发现您关于“jmeter 正确”的断言很可疑。如果 JMeter 正确的话,它应该至少产生一个可比较的平均值。 (2认同)

小智 5

在您的设置中,JMeter饱和的速度快于饱和Web服务器的速度。

您正在高级硬件上运行非常优化的C Web服务器,并在较小的硬件上使用相对较重的Java应用程序对其进行基准测试。优化的C机器代码将(可能)总是比Java字节码更快。JMeter无法跟上Nginx的步伐,因此由于受到硬件限制,因此给您带来奇怪的结果。Java在后台管理硬件资源时会做很多事情,但是在极端的资源使用情况下也会产生无法预测的行为。另一方面,ApacheBench是一个轻量级的C程序,它可以使服务器饱和并且可以产生一致的结果,因为它在使Web服务器饱和之后具有多余的容量。

JMeter非常适合对需要一些时间来处理请求的大型动态应用程序进行基准测试。它提供的所有其他数据都有助于此类Web应用程序。当您在高度优化的Web服务器上处理静态文件服务(几乎是Web服务器可以执行的最快操作)时,您需要一个足够快的工具来跟上。