300,000 MQTT connections to IBM MessageSight for real-time performance testing

As part of our MQTT broker and IoT Platform testing program, we had
previously connected 200,000 simulated connections to IBM MessageSight.


Now we are up to 300,000 simultaneous MQTT connections using
MIMIC IoT Simulator.

Do you see where this is going?

MIMIC MQTT Simulator and Elk Stack

Thinking of feeding MQTT messages of your sensors into an
Elk Stack via a MQTT input plugin?

You could deploy hardware sensors or test clients for your testbed.
Alternatively, MIMIC MQTT Simulator provides a large virtual sensor
network of up to 100,000 sensors per host, so you can rapidly prototype
different types of sensor scenarios and scale up cost-effectively.

MQTT performance methodology using MIMIC MQTT Simulator

Performance of small-scale environments never predicts behavior of
large-scale deployments. But, it is too expensive to setup large numbers
of your MQTT sensors to test your IoT back-office platform, including
MQTT broker and client applications.

With MIMIC MQTT Simulator, it is simple to create large sensor simulations
to verify performance. The methodology is to use MIMIC to simulate a
large environment with synthetic background throughput, then verify
your performance requirements (eg. maximum round-trip delay) either
with a small number of your real-world sensor, or with another MIMIC
setup measuring end-to-end latency. That way you are sure the synthetic
load is not impacting your measurement setup.

In the screenshot above we are running 10 sensors with an end-to-end
measuring instrumentation, and the end-to-end delay is graphed in the
bottom graph. It shows minimum, average and maximum delay for messages
from those sensors to a subscriber running in the same MIMIC.

From another MIMIC instance, we keep adding a synthetic load onto the
MQTT broker under test, from 0 to 1000 in steps of 100. The upper graph
shows the size of the background load over the 15 minutes of the test.
Each background load sensor publishes at 1 message per second, so the
throughput is the same as the number of sensors. This is trivial to
change in MIMIC to conform to your real-world expectations.

As you can see, the delay is only slightly increasing over time, except
for 2 notable bumps at 600 and 1000 sensors. It is trivial to repeat the
scenario, and verify that indeed there is a reproduceable problem. You
would never know if you did not do the tests.

Test your management application with hundreds of Dell iDRACs

Testing your configuration management application or data center
orchestration software for large scalability requires you to setup a
large lab with many servers.

In the case of Dell servers, the Dell iDRAC is a card with out-of-band
control and monitoring of a Dell server. Rather than buying many servers
and hardware, you can simulate the iDRAC and server in MIMIC Web Simulator.

The screenshot below shows the Dell OpenManage Essentials application
managing 100 simulated Dell servers. The simulation allows complete
control to achieve whatever testing or demo scenario you want.

Once simulated in MIMIC, each of these devices are available on
the network as if they are real devices. Your management applications
can access them and have a complete control over their configurations.
You can easily start, stop them and change their parameters at
run time. You can customize the simulation at run-time to introduce
faults.

SNMP Simulators: build vs. buy

Faced with the prospect of simulating large network management
environments, the typical build vs. buy dilemma emerges: should you pay
for a commercial solution, or build one of your own?

There are several free open-source simulators available, promising to tilt
that equation in favor of "build": since a seemingly viable alternative is
already available, you'll just modify what's out there to suit your needs.

This will work out in only the fewest scenarios: the simplest small-scale
simulations.  For most other uses, there are many pitfalls:

1. Meeting the requirements: You have to evaluate the best open-source
for your purposes, and you risk making a sub-optimal choice. You might
pick one, only to find out it does not handle your changing requirements;

2. Developer training: You have to train your developers on the chosen
solution(s), not only from a end-user perspective, but down to the nitty
gritty design, source code and build procedures. You are essentially
investing in something other than your core competency;

3. Quality: Open-source might be high-quality for commodity software
(Linux, OpenOffice), but in highly-specialized areas it usually has few
developers/maintainers, goes out of date, and results in lower-quality
software.

4. Scalability: Designs that work for a small number of simulated entities
usually will not for large numbers due to worse-than-linear behavior of
algorithms. This will usually result in unacceptable performance.

5. Beyond SNMP: Network management applications these days use more
than SNMP to access the managed entities. This requires an integrated
solution that simulates not only the SNMP interface, but also command-line
interfaces (Telnet, SSH), flow-based protocols (NetFlow, sFlow), Web services
(XML, SOAP, REST, etc).

6. Budget for software maintenance: The initial development task is
usually a small part of the total effort. At least one developer has to
continuously maintain and upgrade the software, post messages on some
user groups for getting it built and deployed but also try to get timely
answers for resolving bugs.

 The end result is usually that you'll spend way more effort on the
"build" decision than the cost of the commercial solution would have
been to start with, impacting time-to-market, quality, support, etc.

Many large companies have already chosen to buy instead of spending
effort re-inventing the wheel. Their thinking is that it is better
to spend time and energy behind the companies' core product and services.
Do they know something you don't?

MIMIC SNMP Simulator has been on the market for 20 years. Simulators is all
that Gambit does and has hundreds of man years invested in. The end result
is a mature, high-quality, high-performance simulator that runs at most of
the large networking vendors world-wide. For example, reference customers
are vendors such as Lancope and Xirrus, and end-users such as Pepco and
SITA.

Combined with the other simulators in the MIMIC Simulator Suite you can
have a large realistic environment for development, testing, demo and
training of your network management application.

MIMIC runs on physical servers or the cloud and has been adapted to many
unforeseen uses. For example, Cisco runs MIMIC in combination with Prime
Infrastructure in their on-demand cloud platform dCloud.

Simulate your RelayR IoT environment with MIMIC IoT Simulator

Don't have different types of sensors to test / prototype / deploy your
IoT application on RelayR? Looking to scale without the expense?

Now you can quickly simulate different types of sensors to send MQTT
payload messages at arbitrary rate to your application.  In this
screenshot we quickly setup 4 different sensor types showing dynamic
values changing in the RelayR console.

MIMIC IoT Simulator can simulate unlimited number of sensors of
unlimited variety with unlimited scenarios, all in software. You can go
beyond the requirements so that there will be no surprises after
deployment.

Scale your IBM Bluemix IoT testing with MIMIC MQTT Simulator

Setting up large IoT environments for development, testing and training
is expensive and time-consuming.

Now you can easily scale your IoT environment for testing with
IBM Bluemix with MIMIC MQTT Simulator. MIMIC simulates large
numbers of sensors generating arbitrary MQTT payloads at desired rates
to prototype application policies, test performance under stress, and
develop sales demonstrations and training curricula.

Here we see 10 simulated MQTT sensors connected to Bluemix generating
messages and responding to commands. With MIMIC, what you can do with
10 sensors you can do with 100,000 sensors from one server or virtual
machine on either private or public cloud.