我正在运行一个Ubuntu虚拟机的API服务器的低速率性能测试。API服务器在Azure中的AKS群集上运行，测试VM在Azure中的同一区域中运行。我正在使用JMeter以大约每秒16个请求的速率运行HTTPS端点。
端点与公共IP地址资源相关联，该资源在我在Azure中托管的DNS区域之一中具有“别名”。
间歇性地，JMeter开始失败，同时抛出java.net.UnknownHostException。这可以持续48小时运行中的大约30秒。它会在短时间的故障后自动恢复，但是这种行为会影响我的测试结果，因为故障是由SNUT（JMeter）而不是SUT（我的API服务器）引起的。
PCAP跟踪没有显示任何犯罪迹象：

• 捕获的响应中没有NXDOMAIN、SERVFAIL或其他DNS错误。
• DNS事务开始时会快速连续查找A记录和AAA记录。没有AAA记录，因为服务器位于IPv4世界中，而A记录是我上面提到的Azure DNS“别名”。
• 我观察到127.0.0.1（JMeter）、127.0.0.53（systemd-resolved）、10.50.x.x（JMeter/systemd-resolved VM的面向Internet的接口）和168.63.129.16（Azure DNS）之间的通信，其速率为每15秒1个事务。

网络上没有任何东西显示出明显的DNS错误。有一个隐含的小故障，那就是AAA记录查找。有一次，AAA记录查找没有收到响应，systemd-resolved重试查询，查询在8毫秒内返回。
我非常确定JMeter和systemd-resolved是经过良好测试的软件组件，不应该在我的测试生成的16 TPS下挣扎。
它可以是Azure DNS在168.63.129.16?但是对于来自这台机器的所有DNS查询，我生成大约0.2 TPS（每5秒向168.63.129.16发送一个DNS事务）。
我还怀疑JMeter内部的一些内部DNS缓存在起作用，因为对于我的HTTPS请求，在16 TPS时，我看到从127.0.0.1到127.0.0.53的查询频率要低得多。
说到这里，我开始怀疑是JMeter的某些内部机制和配置在捉弄我。我根本不是JMeterMaven。这对我来说是一个黑匣子。
我真的很感激任何意见或建议，可以指出我在寻找解释的正确方向。
我可以盲目地添加dnsmasq或其他东西，但我不想掩盖这个问题。我想弄明白。
谢谢你阅读这么远！