Question

I got an android application that I would like to send its use log to my server so it would be saved in a database.

Basically I would like to log almost every action the user does, even a simple button click.

Since MQTT is already used in the application I thought maybe it would be good to use it for logging as well.

For example: every time I would like to log something, I would just publish the action through MQTT, then some server-
side service would subscribe to that logging channel, and each time a log publication would arrive, it would insert it to the DB.

However there are several things I’m worried about –

1. I’d like to know if publishing a message of 30 characters each time the user does anything would be heavy on bandwidth.
2. What would be the best solution for a service that would listen to that channel and insert each message into a DB.

Another option is to send the data through a regular REST method, though then I got 2 options, either send it in big bulks (I would have to know when is the right time to send it before the application closes) or send it in real-time when the logging action occurs.

Then I wouldn’t need a service that would subscribe to the MQTT logging channel.

And let’s assume that my server should be able to handle several thousands of users concurrently.

Any interesting thoughts?

Thanks!

Answer 1

If you’re using MQTT already, it makes a lot of sense to use it for your logging. My quick calculation above of the bandwidth requirements show it’s unlikely to be a huge burden. The logging app would have to be able to deal with 2000 messages per second in my example. It would just be a simple MQTT client that also connected to whatever database you use. There is a trivial example for mysql at https://bitbucket.org/oojah/mosquitto/src/426b311d682d/examples/mysql_log/mysql_log.c

Something that you probably do want to consider is the power usage of sending so many events. Stephen Nicholas has carried out two studies on Android looking at MQTT usage, first looking at straightforward MQTT usage in a number of scenarios ( http://stephendnicholas.com/archives/219 ) and second encrypted MQTT vs HTTPS ( http://stephendnicholas.com/archives/1217 ). The points you should consider are the battery cost to keep the connection active and the cost and speed of sending messages. Assuming one message per second, keepalive=240 seconds and that your user has an identical phone to Stephen, you’d consume about 3.1% battery life per hour over whatever else is happening on the phone.