Once you have defined a template, it is time to launch this. In the simulate tab, you see several settings.
Here is a quick explanation of the settings
As we discussed earlier, a template is a recipe from which multiple virtual device objects are created. Each run of the template is assigned a unique name - to differentiate the results. A random name is automatically allocated by the UI but you could modify the name as well.
Number of Clients: Specify how many total clients you want to initiate here. This is limited by your current account settings and can be upgraded based on your license.
Repeat Message: How many messages you would like to send in total throughout this simulation run.
Gap between each message: What should be the interval between sending each message. The minimum value is 1 second and it could be large as well.
Save State Information: You have an option to capture and see state object information for all clients through all iterations. Collecting this information usually slows down result analysis. If you are running a very large test, this parameter may be automatically disabled.
Limit new connections/sec: When a simulation begins, all of the clients start to connect with the server almost all at once. This might be overwhelming for your server if you don't have proper load balancing or not enough resources in system to handle such a large connection request. To limit the total new connections initiated from IOTIFY per second, we have introduced this parameter.
To understand the effect of this parameter, lets consider a case where your server could at max handle 100 new connections per second and you are simulating 150 clients. When the simulation starts, all your 150 clients will connect to the server and since your server can not handle all, it will drop some connections. If the client connection timeout value is 1 second, this will cause 50 clients to fail, as they wont be able to connect within given 1 second parameter.
In order to mitigate this, we will need to limit new connections per second parameter to 100. This will ensure that IOTIFY will not launch more than 100 new connections request per second. So what happens to rest of the 50? They will be launched once the previous 100 clients have successfully connected. This will delay the start of the simulation slightly as now the system needs to wait more for all 150 clients to connect. So using this setting is a tradeoff between increasing your server capacity vs. slowing down the simulation vs. accepting the partial failure in the test results.
Limit max messages/sec: Similar to the new connection/second limit, this parameter will try to spread out the iterations so that not more than specified number of clients will send the message to the server at any given point of time. This again will spread the simulation timing to higher side.
Client ID offset: There may be a case where you want to run 100 clients at once and then start next 100 clients at a later stage. In such scenario, you would like to use the same template. However, problem in this case is that all the clients in the later simulation, will also have their client ID starting from 0, because technically it's just another run of the same template.
In order to solve this, you could provide a client id offset value while you start the simulation. E.g. in our previous example, you could simply provide the client Id offset as 100. This will ensure the new simulation will have client IDs starting from 100 to 199.
As the name implies, network parameter can modify and emulate the outgoing network condition. We have provided some sample profiles to get you started.
It is possible to start the simulation at a later time or create a recurring run with this section. Any future scheduled simulation could be cancelled by going to the result page.