Measuring Publish-Subscribe latency of MQTT
Use Network simulator to measure MQTT publish subscribe latency and plot it using dweet.io and freeboard.io
In this post we will use network simulator to measure the round trip performance of a public MQTT broker. We will mesaure average delay between a publish-subscribe message (loopback). Then we will plot this latency value realtime into the Dweet.io dashboard with just a few lines of code.
This short tutorial will take approximately 10 minutes to setup and requires a free acount with iotify. You could sign up for free here.
Ready? Let’s get started.
For this demo we will use a simple template named latency. Go to the top level Network menu and click on Templates. Create a new template named latency.
The new template will be based on MQTT by default. Let’s keep it that way. You may want to randomize client ID by clicking the light blue button, so that you don’t end up accidentally conflicting with some other user.
For this test, we will use public MQTT broker iot.eclipse.org:1883 but you are free to change the broker if you want. Let’s leave rest of the values as default and go to the message section.
Here, you will need a unique MQTT topic to publish to your broker. In this example we will use /iotifydemo/mqttlatency but make sure you choose a random value, not to conflict with other users.
Now enter following code in function
Important: Please change the CHANGEME value above to a unique identifier. This is required so that you don’t end up choosing the same URL for dweet.io page.
So what did we just do in this template? We simply populated an internal state variable called latency which we report to dweet.io on each message run. We are using get() helper here which performs an HTTP GET request synchronously.
Now let’s setup a subscription handler which will subscribe to the message we just published. Click the checkbox Subscription Handler and enter following code
The subscription handler receives the published message contents and calculates the high resolution time difference. It then updates the state variable with the calculated value.
Make sure that your subscription topic is same as publish topic. Here is how our final template is going to look like.
Final check: make sure you chose a unqiue MQTT topic have provided the common value in both publish and subscribe topics.
Make sure you chose a unique key for Dweet.io url as this is going to be your monitoring page in next step.
Just save the template. It was that easy. Now let the magic begin.
Save this template and you will be directed to Simulate tab. Keep the default values and hit Start simulation button.
That’s it. The simulation will get scheduled at our backend and in a few minutes you will be able to see the progress real time. Now it’s time to see the reported round trip latency.
Open a browser and go to https://dweet.io/follow/YOUR_UNIQUE_KEY. Here the unique key is what you changed in the message contents in step 1.
For us this URL will be https://dweet.io/follow/iotify-demo
As you could see in the dashboard, the average publish-subcribe latency comes a little above 120 milliseconds.
This is the approximate time it takes for the public MQTT server to loopback the data to the same client over internet. It also includes the processing latency at iotify network simulator.
In the Simulate tab, play with various parameters in Network emulation to see the effect of other network condition on your latency.
Change the QoS value from the published message template to see the effect.
Load the public MQTT server with other traffic and see the effect on latency.
Finally build a latency monitoring dashboard using freeboard.io
Liked this or have suggestion for improvement? We would love to see your comments in the section below.