1

(2 replies, posted in wolfMQTT)

Hi embhorn,

Thanks for the quick reply and the clarification.

Yes, I’m using TLS (wolfSSL) on top of the MQTT connection — that’s likely where most of the overhead comes from. The device runs on a lightweight custom TCP/IP stack (similar to lwIP, but trimmed down for our MCU).

I understand that WolfMQTT itself is quite efficient, but it seems the combination of TLS handshakes, message fragmentation, and limited heap memory (only around 64 KB total) might be contributing to the slowdown.

I’ll experiment with matching the MQTT buffer size to the TCP driver buffer as you suggested. Do you recommend keeping the MQTT buffer slightly smaller than the TCP buffer, or the same size?

Also, would using non-blocking sockets help reduce latency under tight memory constraints?

Best regards,
bettylim

I’m using WolfMQTT on a low-memory embedded system and having a hard time optimizing its performance. When sending or receiving larger payloads, the device often slows down or even disconnects. I’ve tried tweaking buffer sizes, QoS levels, and keep-alive settings, but nothing seems to fully stabilize it.

I’ve been studying the examples from the official GitHub repo:
https://github.com/wolfSSL/wolfMQTT slope game

They’re helpful, but I’m still struggling to find the right balance between memory usage and speed on constrained hardware.

Has anyone else faced similar issues with WolfMQTT on small systems?

What buffer sizes or memory management techniques worked best for you?

Does lowering QoS actually improve stability in low-memory setups?

Any specific code tweaks or configuration tricks that made a big difference?

Thanks in advance!