我有一个简单的JMeter实验，使用一个包含16个线程的线程组，运行500秒，每个线程每2秒访问一个相同的URL，每秒生成8个请求。我在非GUI(命令行(模式下运行。这是.jmx文件：
https://www.dropbox.com/s/l66ksukyabovghk/TestPlan_025.jmx?dl=0
以下是在AWS m5ad.2xlarg/8核/32GB RAM上运行的结果图(我在我的PC上的VirtualBox Debian上得到了相同的行为，非常大的Hetzner服务器，Neocortix云服务实例(：
https://www.dropbox.com/s/gtp6oqy0xtuybty/aws.png?dl=0
在线程组开始时，所有16个线程都报告一个长响应时间(0.33s(，然后稳定到一个正常的短响应时间(<0.1s(；开始运行"；问题然后大约220秒后，又出现了一个16个长响应时间的突发，并且在大约440秒处又出现了另一个突发。我称之为"；开始运行回声"；问题，因为它们看起来像"；开始运行"；问题如果我引入另一个有延迟的线程组，比如60秒，也会出现同样的问题。该线程组获得其自己的"线程组"；开始运行"；在t=60s时出现问题，然后在280s和500s时出现自己的回声。
这两个之前的帖子似乎是相关的，但没有给出"；开始运行"；问题，以及"；开始运行回声"；并没有提到这个问题。
Jmeter-http采样器的第一次迭代所花费的时间是大
JMeter 中第一个耗时较长的HTTP请求
我可以围绕"；开始运行"；通过在每个线程中用第一个HTTP请求命中一个不存在的页面，得到一个404错误，并过滤掉404。但这是一个破解，它并不能解决"；开始运行回声"；问题，不能保证会碰到不存在的页面。并介绍了"；孔"；在传递到真实目标页面的负载中。
更新：根据Dmitri T的建议，我已经安装了JMeter 5.3。它的默认值httpclient4.time_to_live=60000(60s(，其输出与之匹配：
https://www.dropbox.com/s/gfcqhlfq2h5asnz/hetzner_60.png?dl=0
但是如果我增加httpclient4.time_to_live=600000(600s(的值；回声"；跑过终点。它仍然在220秒和440秒左右显示回声，即我试图消除的相同原始行为。
https://www.dropbox.com/s/if3q652iyiyu69b/hetzner_600.png?dl=0
我想知道httpclient4.time_to_live是否有220000(220秒(左右的有效最大值
谢谢，Lloyd
由于初始连接建立和SSL握手，第一个请求将很慢
展望未来，JMeter将根据其网络属性采取行动，特别是：
httpclient4.time_to_live-TTL(以毫秒为单位(表示绝对值。不管怎样，连接都不会在TTL之后被重新使用httpclient.reset_state_on_thread_group_iteration-启动新的线程组迭代时重置HTTP状态，这意味着关闭打开的连接并重置SSL状态
此外，您使用的似乎是5年前的过时JMeter版本，根据JMeter最佳实践，您应该始终使用最新版本的JMeter，因此请考虑升级到JMeter 5.3(或JMeter下载页面中提供的最新稳定版本(，因为您可能正遭受已经解决的JMeterbug。
也可能是需要执行操作系统和JMeter调优的情况，请参阅JMeter的并发、高吞吐量性能测试，以了解问题和解决方案