Simulation Orchestration

How does IOTIFY simulates your job when you submit the run? Learn more about our orchestration strategy.

One of the key requirement of a simulator is the seamless scalability without deteriorating simulation performance. IOTIFY is designed to be truly horizontally scalable in this regard i.e. add more agents to the simulation without affecting the baseline performance. The architecture of IoTIFY is based to utilize docker container, which enables a truly distributed system anywhere in the world. As long as the IOTIFY agents have connectivity to your IoT backend, they could run and simulate the job. However, to distribute, orchestrate and collect the results of the test, we have certain internal strategies which are worth having a look.

Let's follow your simulation as it is submitted from either the UI or through the API.

Job Queue

When a job is submitted through the UI, it is sent to an internal job queue. Based on the current availability of the node and the job settings, the total numbers of clients are divided into chunks, let's say 100 each. Simulation for each chunk of client is submitted as a individual job, i.e. your first 100 clients could be simulated by one machine while the other 100 clients could be running on another machine.

When a job is scheduled at a node agent, it first initializes the protocol settings and calls setup function. Note that setup function is invoked before connection to the server is established, i.e. particularly useful if you want to provide credentials for the connection or control which client should connect to which server.

Within the job, all the clients must complete the setup function before the first message function could be run. This also indicates that all clients should successfully connect to the