MQTT compared to HTML for its network saving

I’m interested by MQTT for two reason, the first one is related to its services and QoS management, the second by its network efficiency because I’d like to use it over a 3G communication system with a small and low cost plan.

MQTT promise is to be network efficient but, i’d like to see it with my eyes, so I’ll try to give you some measures I’ve done to confirm it. My fear is that keep alive communication for subscriber costs could be high and request some software adaptations.

See full article to get details and eventually reproduce

Test environment

This test is running on a mosquitto version 1.2 broker, I’ll measure the traffic between a linux system running

  • mosquitto_pub every 1 minute during 5 minutes with following payload (space removed)
  • mosquitto_sub for 30 minutes with a message sent each 5 minutes with following payload

The traffic is measured using wireshark

Test #1 – publish with QoS 0

i=0 ; 
while [ $i -lt 5 ] ; do 
   mosquitto_pub -h myBroker -t sensors/value --qos 0 -m "sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]" ; 
   sleep 60 ; 
   i=$(( $i + 1 )) ; 

tcpdump gets the traffic

tcpdump host myBroker -s 65535 -w /tmp/mqtt_pub

The payload is 198 characters

The measured traffic for the 5 messages is 6000 bytes with 70 packets

The multiplication factor is about 6 time the initial payload in this case.

Each time we publish a message, it costs 1002 byte + payload size

Test #2 – Publish with QoS 1

The same test is executed with QoS set to 1

The payload is 198 characters

The measured traffic for the 5 messages is 5700 bytes with 65 packets

The multiplication factor is about 6 time the initial payload in this case.

Each time we publish a message, it costs 942 bytes + payload size

I was expecting QoS 1 bigger than QoS 0 but we can consider them as equivalent

Test #3 – Subscribe to a topic with no messages for 53 minutes

The system is simply waiting for a message for 53 minutes on an idle topic.

tcpdump indicates 11446 byte exchanged  so we can consider keep alive traffic around 12Kb / hour

Keepalive is a parameter we can change, the problem is to ensure that the router/nat/firewall you can have between you and the broker won’t close the port if unused for too long.

Test #4 – Get a message stored in the Queue with a subscribe (1 shot)

The principle of this test is to store a value in a Topic on the broker to get it asynchronously over moquitto_sub. This is a kind of poll and it can reduce the hourly keep-alive traffic when we do not have to get the message instantaneously.

  • First step : register as subscriber with no clear-session-flag
moquitto_sub -q 1 -c -i device1 -h MyBroker -t sensor/value
  • Second step kill this mosquitto_sub
  • Third step send a mosquitto_pub to the broker on this topic with QoS = 1
mosquitto_pub -h myBroker -t sensors/value --qos 1 -m "sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]" ;
  • Fourth step : start tcpdump
  • Fifth step : restart mosquitto_sub to get the message
moquitto_sub -q 1 -c -i device1 -h MyBroker -t sensor/value

This get a result of 18 packet captured and 1477 byte for the 198b message when a message is delivered.

  • The same test is executed with no new message on the queue

This get a result of 13 packets with 926b transmitted

Test #5 – Publish over http

The principle is to send the same payload over http. The server on the otherside only return OK string with no formated html.

The script use is the following :

i=0 ; 
while [ $i -lt 5 ] ; do 
   wget -O - 'http://mySErver/blank.html?sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]' 2> /dev/null ; 
   sleep 60 ; 
   i=$(( $i + 1 )) ; 

As a result, tcpdump captured, for the 5 messages with the 198 char payload, 7360 octets have been transfered with 50 packets. This is 7,5 time the initial payload size. For each transfer it’s something like 1274byte + payload.

Compared to the measure made with mosquitto_pub, regarding the different QoS case, the saving offered by mqtt is around 22%.

I was expecting more…

Subscribe over http

There is no subscribe method in http, the way to do it will be to poll the server regularly to get information. Polling is like a push with no parameter but returned content and we can expect to get the same volume of data exchanged each poll time. According to the previous tests, it’s about 1200byte / request. Comparing to what have been measured with mqtt, over 10 poll / hour, mqtt is more efficient. As mqtt is getting results instantanously, there is a great advantage to use mqtt.

When real time is not expected, the mqtt saving will be around 23% once again.


I’m sure that in term of service MQTT gives a lot of benefit you can’t have on http. In terms of pure bandwidth saving, I was expecting larger saving than I found in this test. By the way, >20% is something important when you try to save a couple of KBps / hour to keep in a telephony plan.

If anyone have a more scientific study on this topic, I’m interested in reading it ; feel free to comment.


3 thoughts on “MQTT compared to HTML for its network saving

  1. One of the benefits of MQTT is that you can establish a connection and publish/receive multiple messages over it.
    In your tests, you are creating a new connection for each message sent, something you would not do in a real application.
    Maintaining the connection does require the keepalive flow, but the overhead is minimal (4 bytes per ping flow, at a configurable interval) when compared to doing a complete CONNECT flow each time.

  2. Easier loops in bash:

    for i in $(seq 1 5); do
    mosquitto_pub -h myBroker -t sensors/value –qos 0 -m “payload”
    sleep 60

  3. You right, I did not do pub test over an existing connection, this is something I’ll test as it sounds interesting for my project. I was looking for some quick answers to take a decision (I mean be ensure MQTT is less consuming than my current basic http integration).
    By the way, regarding the keep-alive traffic for submission, I assume it costs 12K /hour to keep a publish connection either. This means I will save traffic only if I push more than 10 messages an hour, which is not my case currently.

    I also get a tweet saying it’s unfair to compare MQTT with http get, I assume it is because the service is not the same and the basic get is quite network efficient compared to more advanced protocol to transfer data over http. This is totally right … but in my implementation http get is sufficient to make it works, so why should I compare to something else 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.