3

I was wondering if the MQTT protocol is suited for some high refresh rate data streaming. As it was designed for low-bandwidth high-latency application I was wondering how it would perform in a high-bandwidth low-latency application.

What I want is to send sensor data at a rate of 60-120 times per second. Is this something feasible or will some design decisions in MQTT prevent that from working in a usable manner? I would have full control over the broker in this scenario and it would happen at QoS level 0.

The payload would be a single 32bit float or 32 integer. All devices would connect over wifi or ethernet. Though my questions is really mainly if the design of the proctocol is actively working against this sort of application.

timonsku
  • 1,249
  • 2
  • 21
  • 45
  • 2
    Some MQTT brokers can handle hundreds of thousands of messages per second, so this would be solely client bound. From my experience, a few thousand msg/sec works pretty well for most MQTT clients. – Dominik Obermaier Aug 21 '16 at 19:13

1 Answers1

4

As with all performance type questions like this, there is no definitive answer, it all depends on so many factors.

  • Size of payload
  • State of network between broker and clients
  • Number of subscribers
  • What happens if you miss a message or one is delivered twice

The only way to be sure is to test it and find out.

Having said all that I have known people do VoIP over MQTT in the past

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • I clarified my question a bit but the fact that someone did VoIP over MQTT says quite a lot for my use case. – timonsku Aug 21 '16 at 17:30