Jmeter测试以大约8个从属计算机以主从属方式运行。但是，在将远程批处理模式设置为MODE_STRIPPED_BATCH的情况下，我无法运行超过64小时的测试。吞吐量约为每分钟450个请求，每台从属计算机将导致创建约1.5 gb的jtl文件。所有的8个从站都将把它发送给主站（1.5 gb x 8），并且I / O可能太多而无法由主站处理。主计算机的内存为16 gb ram，磁盘存储量约为250 gb。我想知道jmeter分布式体系结构是否可以进行长时间的浸泡测试，而不会对主机造成任何无法解释的压力。显然，我可以选择放弃主从服务器设置，而选择8个独立的节点，但是在那种情况下，我会在处理数据csv文件（我目前使用主服务器m的简单表服务器插件来服务）方面遇到麻烦。还在汇总结果文件。有任何建议请。能够至少运行约4天（96小时左右）的测试会很棒。
zdh064105 回答：jmeter中的长时间浸泡测试
我的期望是您正在寻找StrippedAsynch采样器发送方模式。
异步
样本被临时存储在本地队列中。单独的工作线程发送样本。这允许测试线程继续运行，而无需等待将结果发送回客户端。但是，如果创建样本的速度快于发送样本的速度，队列最终将填满，并且采样器线程将阻塞，直到可以从队列中清空一些样本为止。此模式对于平滑样品生成中的峰很有用。可以通过在服务器节点上设置JMeter属性
asynch.batch.queue.size（默认为100）来调整队列大小。StrippedAsynch
从成功的样本中删除responseData，并使用异步发送方发送它们。
因此，在从属节点上，将以下行添加到 user.properties 文件：
mode=StrippedAsynch
并在主节点上定义asynch.batch.queue.size，它的值高到对JMeter的吞吐量没有影响（不会减慢它的速度），而它的高到不影响JMeter的吞吐量。我将从1000开始。
另一种选择是使用StrippedDiskStore，但是您必须在测试完成后手动收集序列化的结果（确保从属进程不会关闭，因为从属进程完成后会删除结果）
您可以使用JMeter PerfMon Plugin来监视主服务器和从服务器上的内存和网络使用情况。
,我建议去找一个独立的JMeter员工+外部数据收集器设置。
实际上，JMeter开箱即用的“分布式缩放”功能较弱，过时且总体上很可笑。以及它的数据收集/汇总/处理能力。
这种情况实际上使我感到非常困惑-请注意，竞争对手甚至更糟，因此该领域几乎没有什么（也许某些SaaS解决方案试图通过这种差距获利）。 但这就是它...
这就是为什么为什么 -s，现在是如何 -s。
如果我是你，我会：
-
包含JMeter工作者
-
为每个容器配备一个看门狗，以在本地问题向南移动时（或什至按计划对其进行最终刷新）快速重新启动工作程序。是内部服务还是外部云服务都没有关系。
-
设置时间序列数据库-我推荐InfluxDB，它是一款出色的产品，并且基本版本是免费的（足以满足您的目的）。
-
将测试结果/指标输入该数据库-不要在本地收集它们！您可以使用非常简单的自定义侦听器（Influx线路协议非常简单，快速）在测试中立即完成操作，也可以让外部代理在结果文件流动时对其进行监视。我只是建议您不要使用所谓的Backend Listner来完成这项工作-这是垃圾，不会正确地塑造您的数据，因此您必须执行其他操作才能将它们整理好。
-
如果您正确地调整测试结果/指标数据，就可以将它们与时间同步到一个集合中-并且进一步的处理功能非常强大！