How to right-size your IoT platform

You have run extensive tests on your IoT platform candidates, have gotten
QOS / performance guarantees from the vendor, and have selected the most
promising choice.  You may have even put money down.

Now that you are ready to deploy your IoT platform, these are the problems
you will need to solve:

1. initial configuration

   Likely the IoT platform will need to be tuned to your individual
   requirements in the production environment, which is likely much
   different than your test environment. You may have tested in-house,
   and are deploying on the cloud, or vice versa.
   
   Configuration does not only involve the middleware software components,
   but the OS itself, as we had learned in this post.
   
   For example, it took us multiple tries until we could scale ActiveMQ
   to 20,000 simultaneous client connections. Out of the box, on a 8-CPU
   system, we could only scale to about 800 sessions. Then we applied ARP
   cache- and thread-tuning, and got to 7,000 sessions.  Only on the third
   try did we get to 20,000 sesssions.
   
   You will face this with any IoT platform. With MIMIC MQTT Simulator this
   exercise took an hour including research on this unknown software.
   How long will / would it take you?
   



2. end-to-end tuning

   The process above just gets us part-way to the ultimate requirements.
   There are many variables that impact long-term run-time performance
   in your production environment:
   

   a) connect rate:

   at what rate do clients connect to the broker. For example, your devices
   may all simultaneously connect after a brownout, or there may be a
   steady trickle of sensors connecting and disconnecting during the day.
   Every scenario is different.
   

   b) publish rate:

   how often do clients publish telemetry? How large and what size
   distribution do the messages have? What QOS and encryption
   parameters are being used? The scenario of 1 message every minute
   with 100 bytes per sensor is quite different from a camera publishing
   hi-res images at 10 / second.
   

   c) consumption rate:

   how many applications are consuming messages? Since the broker is
   essentially a layer 4 switch, the fanout determines switching
   performance. Wildcard topic subscriptions challenge topic matching
   algorithms. Are your consumers running with enough power to not bog
   the broker down?
   
   MIMIC MQTT Simulator is highly customizable allowing you to vary all
   these variables to run many end-to-end scenarios to ensure adequate performance.
   
   

3. devops

   You have your production system running, but how do you test that it
   scales up and down with varying performance levels? How do you test
   changes to your applications while it is running?
   
   With MIMIC you can run synthetic loads even on your production system
   to verify operational adjustments. Your broker cluster should absorb the
   extra load, and contract when the load is gone. By generating custom
   payloads you can test new features and fixes to your consumer application.