Are you implementing LWM2M-MQTT in your environment?
MIMIC MQTT Simulator supports arbitrary payloads for MQTT messages
for a large number of simulated MQTT-enabled devices.
You can use it to quickly prototype your LWM2M-MQTT implementation.
In particular, you can test scalability of your LWM2M server over the MQTT
transport.
Check this 2-minute video that shows 2 sensors publishing unique telemetry
to Eclipse Leshan.
Monday, September 18, 2017
Thursday, September 14, 2017
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:
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:
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?
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.
-
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.
Subscribe to:
Posts (Atom)