您好,我在emqx中启用了超级用户,并将发布客户端设置为了超级用户,根据官方文档中所描述的"超级用户拥有最高权限不受 ACL 限制",如果是因为ACL检查而导致耗时久的问题,我这样设置应该就可以规避这个原因(测试前已清除ACL缓存),但是,实际上,我的吞吐量并没有提升…请问还有其他的可能原因吗?
- 如果猜测是 ACL 的问题可以先关闭 ACL 在测试看看是否有优化？
- 需要确定下执行 onMessagePublish 的机器和 Broker、还有发布的客户端时间上是不是一致的
- 这些都没问题，可以先把 exhook 关掉试试看，是否还存在这么高的时延
好的,我去试试
多个线程同时使用一个user,clientid去pub消息？这个恐怕超过了物联网mqtt的适用场景。
一般一个客户端、一个user/clientID，一秒一个，这样发数据，才有必要使用mqtt/emqx.
要多线程发，可以创建多个user/clientid,然后分配给每个线程。
我们有一个云中台的概念,部分类型的消息要通过云中台发送给设备,
那pub端（springboot多线程程序）到broker，耗时超过2~3s，这个，不算长。
你这个检测 多长时间内 broker能收到数据，也是你 也是单独写了个程序、订阅后 获取的。订阅程序建立连接，获取、打印、算时间差，这里就有延迟（如果你这个服务器正在接收大量mqtt客户端的发送消息，性能更会受影响）。
这个就是使用mqtt的坏处、就是它一定要订阅才能获取消息。（它的好处是建立消息 传递的标准化流程、减少编程任务）
自己编程使用socket发送，就不会这样。
1）用不同user/clientid
2) 合并topic（不要每个设备一个topic)
你好
- 通过抓包发现,消息从pub端到broker并没有消耗太多时间,而是在broker内部处理花费的时间比较久,我们的设备是在建联的时候就已经自动订阅了自己相关的主题,因此消息下发的时间不包括建联和订阅,仅仅只是发送消息的耗时.
- 由于业务原因,我们希望对每个设备进行精准控制,因此无法使用共享主题.
是的。这个就是使用mqtt server的坏处：你无法控制一个消息，在服务器内部收到后，具体 做了哪些事情、花了多长时间。
emqx的代码估计很复杂，你也看不懂、也改不了。你只有 被动，地去订阅。
赞同