Understanding Latency

What happens when you launch a simulation on IOTIFY platform?

Measuring IoT messaging latency is one of the most important test for an IoT cloud platform performance. Based on your system requirement, you may have a strict limit on the maximum latency between the response of the system and triggering of an action. The messaging latency is affected by several factors namely -

  • Transmission network latency

  • Platform processing latency

  • Reception network latency

1. Submission Latency - The time taken from actual submission of the test from the UI to the moment when it actually gets scheduled in a worker node. 2. Setup Latency - The time taken to run Device Setup function and then establish a connection to the destination server for all of the clients.3. Spread Latency - If there are more than one clients, a chunk of them will be scheduled in parallel within a single Node process and CPU. This will cause every client to slow down a little bit. 4. Server-side latency- When all clients connect in parallel, it takes sometime before the server could allocate resources to accept all of the incoming requests. This will cause every parallel client to wait. Also, the RTT of the network will be included here. 5. Result publication latency - When a single client iteration is finished, the connection is torn down and the result is published to a fast in-memory cache. Then the next execution begins. More information about these latencies and way to reduce - 1) Is usually variable in the public domain as it depends on the current load of the system. This won't be an issue in the enterprise version as there are no clients sharing the workspace. 2) and 3) are the direct function of the number of clients being simulated in the group (i.e. together in the same container/process/CPU). It increases non linearly with the number of clients. It can be reduced as I explain later. 4) Is actually due to Server side TCP socket and OS/Application availability/architecture. In order to minimize it a front-end Nginx proxy helps. 5) If the save state information button is unchecked - this latency could be minimized. Currently, 1000 clients are executed within the same container/process/CPU so latency 3) is very high. The test is executed such that unless the results of all 1000 clients are available, the next iteration cannot start. This causes entire iteration to spread up to 2-3 seconds (counting the effect of latency 4) as well)The best way to measure raw latency is to run the test with a single client and no save state information. I did that and saw that test finished exactly within 1 minute