基于JMeter在AWS DLT中定义吞吐量及相关配置的技术问询

问题1：配置任务数（Task Count）和并发数（Concurrency）时，该并发值是否会完全覆盖JMeter脚本中的“线程数（Number of Threads）”定义？如Blazemeter等工具可通过不设置并发值来切换该功能的启停。 #

AWS DLT的Concurrency参数会完全覆盖JMeter脚本中线程组的Number of Threads设置。当你在DLT控制台指定并发数后，每个任务节点运行的线程数为总并发数 / 任务数，脚本内的线程数配置会被直接忽略。

如果想要保留脚本自身的线程数定义，不要在DLT配置中设置Concurrency值，此时DLT会直接沿用脚本内的线程组配置逻辑。

问题2：上传JMeter脚本时，是否有标准方式定义吞吐量？我尝试在脚本中使用吞吐量整形定时器，但与AWS DLT测试配置兼容性不佳，实际每秒请求数（Rp/s）远低于定时器设定值，且已确保AWS DLT并发值足够支撑目标RPS，仍无改善。 #

AWS DLT本身没有内置的吞吐量控制参数，推荐按以下方式处理：

• 优先使用JMeter的Constant Throughput Timer，它与DLT的兼容性更好，能更稳定地控制RPS；
• 若必须使用吞吐量整形定时器，需确保脚本中无冲突的定时器或逻辑，同时确认DLT任务节点的CPU、内存资源充足，必要时可提升实例规格；
• 也可以通过公式间接控制吞吐量：目标RPS = 并发数 / 平均请求响应时间，提前压测得出平均响应时间后，反推所需的DLT并发数。

问题3：提交包含非jmx文件的Zip包至AWS时，需在根目录放置含所有脚本用到的插件.jar文件的插件包，是否还有其他文件相关注意事项？ #

除插件Jar包外，还有这些关键注意事项：

• Zip包根目录必须直接包含主JMeter脚本（.jmx文件），不能放在子文件夹内，DLT仅扫描根目录的jmx文件作为执行入口；
• 若脚本用到CSV等外部数据文件，需将其放在Zip包根目录，且脚本内使用相对路径引用（如./data.csv），避免绝对路径；
• 确保所有依赖文件（插件、数据文件）的权限正确，防止DLT任务节点无法读取；
• 不要在Zip包中包含日志、临时文件等冗余内容，避免占用额外存储空间和加载时间。

问题4：AWS DLT中定义的并发数是否适用于脚本中的所有线程组？ #

AWS DLT的Concurrency参数会平均分配到脚本中的所有线程组。例如总并发数设为100，脚本包含2个线程组，那么每个线程组会被分配50个线程（DLT会覆盖每个线程组原有的线程数设置）。

如果需要针对不同线程组设置不同的并发比例，不要在DLT中设置总并发数，直接在JMeter脚本的每个线程组中定义对应线程数即可。

内容的提问来源于stack exchange，提问作者Luke