Why does MQTT acknowledge so slow?

0
votes

I wrote an MQTT client program, which runs at a computer (computer 1). The MQTT client program connects to an MQTT Broker with QoS=1 and publishes data to Broker periodically. I subscribe the Broker (Qos=1) from another computer (computer 2), using Mosquito utility. I found the data published to Broker will be delay delivered to publisher about 3 seconds. The delayed time is too long. I checked the codes and found the 3-second-delay time is from read_packet() which is to read back acknowledge from Broker. Why is there such long delay time? How can I figure it out? The Broker (MQTT server) is managed by my coworker. If the Broker is the cause, I can request them to help. But I need to know what could be the trouble source, so that I can check with them.

I can confirm the delay occurring at the time of reading back acknowledge from Broker by watching the debugging message from MQTT client program at computer 1. For Qos = 1, the client must read back acknowledge after sending (publishing) packets. I found 3-second delay time between sending packet and reading back acknowledge. Surely, I also found the delay at display of Mosquito_sub utility.

1
mqtt
Please clarify your setup: You got 2 clients, first is periodically publishing a topic with QoS=1 and the other subscribed to it (QoS?). Where exactly you notice the delay? Publish from client1 to broker or delivery of message from broker to client2 or PUBACK from broker to client1 ? – Odysseus
Perhaps start by testing against another broker; either a free internet based one (say mosquitto or hive) or a locally installed one (Mosquitto is easy to get running). If there is no issue when publishing a comparable message to another broker this would suggest the issue issue is with your broker or the network between you and the broker. – Brits
@Odysseus The number of subscribers should have no effect on responding to a publish from a client, the broker should not be sending anything to the subscribers until it's finished the QOS handshake with the publisher. (There is no end to end delivery notification in MQTT). – hardillb
@hardillb The MQTT spec says that the receiver can initiate forward message delivery before sending PUBACK. So if there is any subscriber, the broker might (not necessarily) forward the message first which results in a later PUBACK – Odysseus
@StanHuangatTaiwan this appears to indicate that the issue is with your application (assuming your test client/topic/message matches that used by your application). At QOS1 there is a single ACK so I don't think this is a broker issue (given no delay when using mosquitto_pub). The next step is probably to make a Minimal, Reproducible Example you can post here (quite possible you will find the problem whilst creating the example). Testing with a local broker would enable you to fully eliminate the broker as a cause. – Brits

1 Answers

1
votes

Assuming near instant network comms and nothing else strange going on the fact that you have recreated the problem with mosquitto_sub then this points to the MQTT broker being the source of the problem.

Without knowing what broker you are using and how heavily it is loaded it's hard to say more but you should look at the broker logs.