peterhinch / micropython-mqtt

A 'resilient' asynchronous MQTT driver. Recovers from WiFi and broker outages.
MIT License
549 stars 116 forks source link

Usage question: Parallel publications #53

Closed JJGO closed 3 years ago

JJGO commented 3 years ago

I'm gone through the docs but I'm still unclear whether submitting publications in parallel using asyncio is recommended or not. I've tested it with uasyncio.gather, but I had to add qos=1 because some publications were missing. I did this because for web sockets, asyncio is considered a good solution (hence the typical example of running a dozen http requests with asyncio).

So the question is what is the recommended practice when needing to publish to a few topics at once: 1) submitting the tasks in parallel and doing uasyncio.gather or 2) awaiting on them serially (in case they could step on each other).

I tested and both work I just wanted to know which one is more performant given the implementation.

peterhinch commented 3 years ago

Concurrent publications should work because each qos==1 publication has a distinct pid.

On the other hand publishing serially will reduce the resources used. The choice may be a tradeoff between performance and RAM use. With a local broker serial access may be fast, but where the broker is remote, concurrent publications may reduce overall latency.

JJGO commented 3 years ago

Fantastic, thank you! That's exactly what I was looking for.

As a piece of anecdotal data, with a ESP8266, serializing qos==1 with large payloads (~300bytes) worked better than running them in concurrently whilst for small payloads (10 bytes) with qos==0, either setup worked pretty similarly.

peterhinch commented 3 years ago

This is probably down to the limited RAM on an ESP8266. A conservative approach, minimising the number of tasks, is generally best on that platform.