多个线程使用同一个客户端连接，持续发布消息，会对消息的流转性能有影响吗？

EMQX
1

错误报告

环境

  • EMQX 版本：4.4.7
  • 操作系统版本：centos

重现此问题的步骤

  1. xxx
  2. xxx
  3. xxx

预期行为

实际行为

功能请求

描述你需要的功能

为什么你需要这个功能

其他

java项目中使用spring integration集成mqtt，采用多线程持续发布消息，消息等级为qos0，日志显示消息从pub端到broker耗时超过2~3s，请问什么原因可能导致出现这样的耗时？多个线程使用同一个客户端连接发布消息会对emqx的性能造成影响吗？

2

方便提供下日志吗？

3

日志是我在exhook onMessagePublish 回调函数中打印的时间戳以及消息pub的时间戳, 两者的差值算出的耗时

4

ExHook 的 onMessagePublish 回调中你还有做什么操作吗？因为 4.x 还是同步机制，所以各个事件回调的运行速度会影响到消息发布性能。

5

没有其他操作,只是打印了时间戳,官方文档中描述的onMessagePublish回调是挂载在broker发布消息前,那么消息从pub客户端到broker就已经很慢了.

6

当前的消息吞吐大概是多少？

7

300左右

8

我猜测是消息到达慢了，你可以在 EMQX 这边抓个包看下。

9

抓tcp的包吗?

10

是的

11

您好，耗时久的情况只有在持续压测的时候才会发生,我抓完包之后,该如何分析呢.下面是我抓的包

image
image2025×491 59.6 KB

12

可以用 Wireshark 打开，然后比较下报文中的时间戳和报文到达的时间。

13

好的,我去试试

14

您好,我刚用wireshark分析了一下,发现报文到达broker的时间和pub时间基本没有相差太多 ,但是onMessagePublish回调函数中打印的时间与报文到达时间相差较多,这是什么原因呢?报文到达broker之后,onMessagePublish函数执行前,这段时间emqx做了哪些工作呢?

15

你还有启用其它什么功能吗？比如 ACL？

16

acl是有启用

17

默认情况下 ACL 缓存是启用的，所以同一主题下不会每条消息都进行检查的。你发布的消息使用的都是不同的主题吗？

18

是的,都是不同的主题

19

那估计是 ACL 检查花的时间太久了，你 ACL 的数据源是什么？

20

mongodb