英文:
JMeter - first sample in each thread is slow, and problem repeats every ~210s later
问题
以下是翻译好的内容：
我有一个简单的JMeter实验，其中包含一个单一的线程组，有16个线程，在500秒内运行，在每个线程上每2秒命中相同的URL，每秒生成8个请求。我在非GUI（命令行）模式下运行。以下是.jmx文件的链接：
https://www.dropbox.com/s/l66ksukyabovghk/TestPlan_025.jmx?dl=0
以下是结果的图表，运行在AWS m5ad.2xlarge / 8核心 / 32GB RAM上（在我的PC上的VirtualBox Debian，非常大的Hetzner服务器，Neocortix Cloud Services实例上都出现了相同的行为）：
https://www.dropbox.com/s/gtp6oqy0xtuybty/aws.png?dl=0
在线程组的开始阶段，所有16个线程报告长的响应时间（0.33秒），然后稳定在正常的短响应时间（<0.1秒）。我称之为“开始运行”问题。然后大约220秒后，又出现了另外16个长响应时间的突发，然后在大约440秒处又出现了另一个突发。我将这些称为“开始运行回显”问题，因为它们看起来像是“开始运行”问题的回显。如果我引入另一个带有延迟的线程组，比如60秒，那么该线程组在t=60秒时会出现自己的“开始运行”问题，然后在280秒和500秒时出现自己的回显问题。
这两个之前的帖子似乎有关联，但没有得出“开始运行”问题的明确原因，也没有提到“开始运行回显”问题。
https://stackoverflow.com/questions/10982428/first-http-request-taking-a-long-time-in-jmeter
我可以通过在每个线程的第一个HTTP请求中命中一个不存在的页面，获得一个404错误，并过滤掉这些404错误来解决“开始运行”问题。但这只是一种权宜之计，并没有解决“开始运行回显”问题，而且不能保证一定会命中不存在的页面。而且它会在传递到真实目标页面的负载中引入“空白”。
更新：在Dmitri T的建议下，我安装了JMeter 5.3。它具有默认值httpclient4.time_to_live=60000（60秒），其输出与此匹配：
https://www.dropbox.com/s/gfcqhlfq2h5asnz/hetzner_60.png?dl=0
但是，如果我将httpclient4.time_to_live的值增加到600000（600秒），它并不能将所有的“回显”推到运行结束之后。它仍然在大约220秒和440秒处显示回显，即我正在努力消除的原始行为。
https://www.dropbox.com/s/if3q652iyiyu69b/hetzner_600.png?dl=0
我想知道httpclient4.time_to_live是否有一个有效的最大值，大约为220000（220秒）左右。
谢谢，
Lloyd
英文:
I have a simple JMeter experiment with a single Thread Group with 16 threads, running for 500s, hitting the same URL every 2 seconds on each thread, generating 8 requests/second. I'm running in non-GUI (Command Line) mode. Here is the .jmx file:
https://www.dropbox.com/s/l66ksukyabovghk/TestPlan_025.jmx?dl=0
Here is a plot of the result, running on an AWS m5ad.2xlarge / 8 cores / 32GB RAM (I get the same behavior on VirtualBox Debian on my PC, very large Hetzner server, Neocortix Cloud Services instances):
https://www.dropbox.com/s/gtp6oqy0xtuybty/aws.png?dl=0
At the beginning of the Thread Group, all 16 threads report a long response time (0.33s), then settle in to a normal short response time (<0.1s). I call this the "Start of Run" problem.
Then about 220s later, there is another burst of 16 long response times, and yet another burst at about 440s. I call those the "Start of Run Echo" problem, because they look like echoes of the "Start of Run" problem. The same problem occurs if I introduce another Thread Group with a delay, say 60s. That Thread Group gets its own "Start of Run" problem at t=60s, and then its own echos at 280s and 500s.
These two previous posts seem related, but no conclusive cause was given for the "Start of Run" problem, and the "Start of Run Echo" problem was not mentioned.
https://stackoverflow.com/questions/10982428/first-http-request-taking-a-long-time-in-jmeter
I can work around the "Start of Run" problem by hitting a non-existent page with the first HTTP request in each thread, getting a 404 Error, and filtering out the 404's. But that is a hack, and it doesn't solve the "Start of Run Echo" problem, which is not guaranteed to hit the non-existent pages. And it introduces "holes" in the delivered load to the real target pages.
Update: After suggestion from Dmitri T, I have installed JMeter 5.3. It has default value httpclient4.time_to_live=60000 (60s), and its output matches that:
https://www.dropbox.com/s/gfcqhlfq2h5asnz/hetzner_60.png?dl=0
But if I increase the value of httpclient4.time_to_live=600000 (600s), it does not push all the "echoes" out past the end of the run. It still shows echoes at about 220s and 440s, i.e. the same original behavior that I am trying to eliminate.
https://www.dropbox.com/s/if3q652iyiyu69b/hetzner_600.png?dl=0
I am wondering if httpclient4.time_to_live has an effective maximum value of 220000 (220s) or so.
Thank you,
Lloyd
答案1
得分: 2
未来，JMeter将根据其网络属性来执行操作，特别是：
httpclient4.time_to_live- TTL（以毫秒为单位）表示绝对值。无论如何，连接都不会超过其TTL被重复使用。httpclient.reset_state_on_thread_group_iteration- 在开始新的线程组迭代时重置HTTP状态，这意味着关闭已打开的连接并重置SSL状态。
此外，似乎您正在使用已经过时的JMeter版本，该版本已有5年历史，根据JMeter最佳实践，您应始终使用最新版本的JMeter，因此考虑升级到JMeter 5.3（或者从JMeter下载页面获得的最新稳定版本），因为您可能正在受到一个已经解决的JMeter错误的困扰。
还有可能情况是您需要执行操作系统和JMeter的调优，例如，可以查看使用JMeter进行并发、高吞吐量性能测试，了解问题和解决方案。
英文:
The first request will be slow due to initial connection establishment and SSL handshake
Going forward JMeter will act according to its network properties in particular:
httpclient4.time_to_live- TTL (in milliseconds) represents an absolute value. No matter what, the connection will not be re-used beyond its TTL.httpclient.reset_state_on_thread_group_iteration- Reset HTTP State when starting a new Thread Group iteration which means closing opened connection and resetting SSL State
also it seems that you're using kind of outdated JMeter version which is 5 years old, according to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.3 (or whatever is the latest stable version available from JMeter Downloads page) as you might be suffering from a JMeter bug which has been resolved already.
It might also be the case you need to perform OS and JMeter tuning, see Concurrent, High Throughput Performance Testing with JMeter for example problems and solutions
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论