Open tbultel opened 5 months ago
I found the reason in the lib. This is due to the implementation of MQTTAsync_processCommand
Namely, when disconnected, the command queue keeps growing and the while(..) loop iterates through it all the time. After some thousands of queued messages, the time spent becomes significant.
Is this something that should be reported to the upstream Paho C library?
Hello, I have encountered a similar problem as you. I use paho.mqtt.c version 1.3.13, mqtt version is 5.0, running on an embedded device, the system version is debian 10. MQTTAsync runs for a long time, and the system CPU usage rate reaches 200%. What is your solution?
Hi, I am currently using v1.3.1 with paho.mqtt.c submodule
In my test case, I have got a single async_client that pushes messages to the broker. The configuration is no persistence, and the client can keep 180000 messages upon connection lost.
a) When the connection is fine, the MQTTAsync_sender thread takes 2 to 4 % of one CPU. b) When the connection to the broker is lost, then the thread quickly jumps to up to 48% of CPU load c) When the connection comes back, MQTTAsync_sender goes back to 2% , but seems to not deliver messages as fast as before (checked with push and deliver counters), slowly enough to not reach the speed I need.
d) Finally, it is worth to notice that pushing is asynchronous indeed, but takes a significant amount of CPU load of the caller, making is hard to use in realtime contexts (I had to add an intermediate queue so solve this)
The most annoying thing are points b) and c), I am currently trying to understand what is possibly wrong in the implementation. Does anyone have faced it ?