This winter Belarus had just a few sunny days, so we are looking forward to some spring sun in March. And as the weather changes flespi starts to release its long-awaited features one by one — the features that sometimes took months to develop.
But before listing of all new staff we did in February let me tell about the uptime. We finished February with 99.971% uptime, but this time it is totally due to connectivity problems in the uplink provider — things outside of our direct control. On Sunday (February 10) there were maintenance operations in the datacenter and our racks were unavailable for 5:32 minutes. Next Saturday there were MPLS link problems in NL-IX that brought another 2:02 minutes of partial unavailability.
The platform itself was 100% stable in February despite all new upgrades that we installed and, as usual, there were a lot of them.
- The most visible released feature in February is our new tool — SetBox. This is an open-source component embeddable in various applications that allows configuring tracking devices via flespi in an individual and batch mode. Its live version maintained and upgraded by the flespi team can be embedded into various applications to complement them with all the power of devices configuration flespi provides.
- Together with SetBox, we delivered the direct connection to the flespi team via Telegram Messenger — our HelpBox bot. We strongly believe in real-time text communication that is faster and handier than other communication options. One day, when Whatsapp provides a nice API for communication, we may integrate with it as well. But currently, Whatsapp is was behind Telegram in terms of automation possibilities.
- After a lot of internal optimization we’ve done in recent months, we decided to run a performance benchmark of the telematics gateway to better understand our capabilities. The results are very promising — the platform itself is capable of passing 14,000 messages/second in a single TCP connection and deliver all these messages to a consumer via MQTT with 20ms average delay. We also tested the scalability and ran the same test with 10 parallel TCP connections. We got ~80.000 messages/second throughput and were limited by the 200 MBit/s network from the test host. As we know from inside, the flespi system is easily horizontally scalable, so these numbers are great.
- Immediately following the performance tests we decided to enlarge some storage limits for our Commercial users as many of them are already exceeding the channel storage limit of 1GB per day and need to implement alternative storage for backup purposes. First, we made it possible to specify storage duration in hours instead of days in the flespi panel GUI. And second, most important, we enlarged the channel and stream buffer size limit to 10GB. This became possible thanks to a lot of improvements we implemented in our storage engine recently.
- As our storage system is 100% developed in house and we would like to add more and more features and optimizations to it, we need a stable backup in case something goes wrong. In February we developed such a system. For all storage containers, including telematics devices which raw messages are based on containers, and for MQTT retained messages storage we are now regularly doing full snapshots of all data. In case of failure of part of the database, when all mirrors are dead and we are unable to recover in a normal way, we implemented an automatic data restoring procedure from a recently generated snapshot. We do daily data snapshots for each container and hourly snapshots for each MQTT retained messages storage. We store snapshots for 10 days. The good thing here is that we made these snapshots available to our users as gzip files — the archives of all messages for the date. So far it is available in REST API only for devices and containers, but soon we will add it to flespi.io GUI and will post a special blog article about it. We do not count and do not bill our Commercial users for the snapshots storage — it’s free for everybody.
- Following flespi NOC messages replication directly into flespi.io GUI, we decided to republish flespi news messages in flespi panel notifications as well. In the flespi news Telegram channel, we post all new blog articles and some interesting information about flespi, so it is now immediately delivered to the logged users.
- As each day we are acquiring more and more users from North and South America, we added the 3rd node to our automatic downtime detection system from the North America continent. With this node, which is now a part of the flespi cloud, we are also testing the hosting provider as in our plans for 2020 is the distribution of the flespi cloud platform worldwide.
- For our MQTT users, we have two new features in the flespi MQTT broker. First, for CONNACK packet sent as an acknowledgment of the connection from the broker we put information about token used for authentication in user properties. Also for existing MQTT sessions, we put information about active subscriptions for this restored session there. The last one is extremely convenient for developers and I hope it can be included in the next MQTT standard for other brokers as well.
- Second MQTT feature is sticky shared subscriptions — the possibility for shared subscriptions to specify topics that will be used for routing messages for these topics only to specific MQTT session, even if it is offline. This is an important feature to correctly load-balance MQTT messages between multiple nodes in which receiver can be sure about getting all the messages targeted to specific topics and they won’t be randomly distributed among other receivers.
In March we are crossing fingers and hoping to install the first version of flespi analytics systems doing calculations over device messages in real time. This system will serve as the basis for reports and notifications/events engine. Currently, we are developing its second version and chances are that by the end of March it may be available in the platform via API.
Another long-running project is a special open-source application for visualizing MQTT messages onto the customized dashboards. And as we put everything into MQTT — devices telemetry, logs, current statuses of users/channels/devices etc. — it can be a great tool for visualizing telematics information.
The more sunbeams will touch our bodies this spring, the more features we will deliver for the flespi platform. It does not mean that we are driven by photosynthesis — it means that we are just people and sunny spring after a dull winter will give us positive emotions that will, in turn, affect our results.