0

我每秒发送大约 20,000 条消息,这些消息可以跨越多个任意线程(消息在发送到 MQTTnet 之前被处理)。

我发现,线程越少性能越好,超过 16 个同时发送者会导致 MQTTnet 停止运行,即使每秒有 10k 条消息。

慢的不是线程,我每 10 秒轮询一次 MQTTnet Managed Client 缓冲区大小,并看到它增加到变满的程度(在我设置的限制处)。

这是最新的代码版本,也是我几个月前(从今天 2020 年 8 月开始)注意到的——它在我最近的 ThreadRipper 系统升级中突出显示,我的代码创建的线程数等于环境处理器的数量——相同的代码基础但 8 与以前的硬件与 48 在新硬件上导致“失败”。

48 个解码/发送线程导致 MQTTnet 停止运行,而 4 到 8 个线程正常且性能良好。当使用更高的线程数时,我可以看到 NIC 到 MQTT 服务器的速度从 8Mbps(4 到 8 个发送线程)下降到不到 100kbps。

本地或远程 MQTT 服务器没有区别 - 如前所述,我可以看到 MQTT 中的发送缓冲区增加,并且会一直这样做,直到内存耗尽,除非设置了限制(无论哪种方式,它都会在线程的胁迫下并在此状态下丢弃消息) .

请注意,在这两种情况下,每秒发送的消息总数保持不变 - 唯一的变量是发送消息的工作线程数。

这是一个错误,还是我做错了什么?我是否应该创建自己的队列来前端托管客户端并一次调度一个(我不想重新发明轮子,但想确保我正确使用库)。

4

1 回答 1

0

我发现这似乎与调试有关,并且在没有调试的情况下启动 - 没有调试的启动速度要快得多,并且可以一直扩展到 48 个线程(根据环境处理器数量),在没有任何排队的情况下启动时没有任何问题。

奇怪的是,由于两种情况下的消息量相同,唯一的区别是提到的线程数(即使使用调试和 8 个线程,调试也可以跟上没有问题)。

使用多个发送线程进行调试时似乎存在开销 - 这可能很明显,但找不到警告的位置。

于 2020-08-07T19:32:04.933 回答