Measuring Publish-Subscribe latency of MQTT

Use Network simulator to measure MQTT publish subscribe latency and plot it using and


IoTIFY’s network simulator is a powerful cloud based tool to create intelligent IoT simulation. Unlike other load testers which generate dumb traffic to cloud, IoTIFY Network simulator is smart and completely customizable. With its Javascript syntax, the tool could be used to perform variety of use cases.

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 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.

Step 1. Create a simple template

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 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

//Initialization of the latency field
if (state.latency === undefined) state.latency = [0,0];

//please change this to a unique value before running this template.
var unique_key = "CHANGEME";

// report latency in each run
var query = ''+ unique_key +'?second='+state.latency[0]+'&nanosecond='+state.latency[1];

//return an array value of high resolution current timer
return process.hrtime();

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 page.

So what did we just do in this template? We simply populated an internal state variable called latency which we report to on each message run. We are using get() helper here which performs an HTTP GET request synchronously.

Step 2. Setup subscription handler

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

//passed parameters to this function are:
//message: received message (string)
//state: current object state, passed as reference

//Incoming message is in "1211,1211212" form
var msg = message.split(",");
var start = [];
start[0] = parseInt(msg[0]);
start[1] = parseInt(msg[1]);

//update latency
state.latency = process.hrtime(start);
//no need for return

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 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.

Step 3. Run the newly created template.

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 Here the unique key is what you changed in the message contents in step 1.

For us this URL will be

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.

The next steps

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

Liked this or have suggestion for improvement? We would love to see your comments in the section below.