emq往主题A发送消息到收到设备响应消息，这个过程应该很短，大概十几毫秒左右算正常。
实际上，通过日志追踪，以及相关服务的后台日志（在某些关键服务上打印了时间戳），发现上述过程耗时数秒，有的甚至超过十秒，查看emq的dashbord，在慢订阅菜单中会出现大概十条左右的记录。
请问是什么原因导致消息发送和接收需要耗时这么久？
EMQX 往设备发送消息到设备回复响应之间的时间长，不应该从设备端入手吗。你这个大概率是设备处理不过来了。
emq发送消息到设备收到消息，这个过程大概需要1~2秒，从设备发送消息到emq收到设备响应消息，这个过程也需要大概1~2秒，如果说emq到设备可能是设备处理不过来，那设备到emq呢？为什么也需要1~2秒。。
“从设备发送消息到emq收到设备响应消息”，没太理解这句话的意思，有详细的日志吗？可以发上来看看。
您好,我昨天又重新测试了一下,抓取并整理了链路中各个节点的耗时情况,发现确实是emq发送消息到设备耗时最久，之前发现的设备到emq耗时久可能是偶现情况。还是有些疑问，我的压力机是4c8g，带宽为10M，开了100个进程，每个进程100个线程，共计模拟10000个设备，连接到broker。测试机为4c8g，带宽5M，并发量500，持续30min。整个压测过程中，各个部分的cpu和内存都正常。通过emq的日志追踪查看到在30min内，某个设备收到54个消息，其中有16个消息从emq发送到设备耗时超过了1s，为什么会出现这样的情况？设备内部处理逻辑是：收到消息立即响应。
你现在理论上流入emqx的每秒吞吐是多少？以及从emqx流出到设备的每秒吞吐是多少？设备能处理的过来这个吞吐量吗？
500的并发量,理论上至少有个每秒500的吞吐量吧,实际上测试只有300左右的吞吐量,每个线程为1个设备,每个设备有自己单独的topic.设备肯定是能处理过来的,毕竟对于单设备来说,它在压测时间内,也没收到多少消息.
所有设备加起来每秒500吗？还是每个设备500？你在EMQX中还启用了什么功能吗？
所有设备加起来500,emq启用了统计分析里的主题监控,慢订阅和日志追踪,另外还配了规则引擎.
规则引擎里面用了什么功能？4.x版本的规则引擎还是同步阻塞机制，所以如果外部资源响应慢的话也会影响吞吐
配置的规则不在我本次业务流程中,属于其他功能的规则,应该不会阻塞我的流程.
