Memory

To achieve better performance on the station we recommend increasing the memory heap size of the JVM process running the station.

To do that:

1. Go the Daemon User Home folder.

   

2. Then the etc Folder.

   
   
   

3. Then edit the file nre.properties.
   
   
   
   
4. Then increase the value -Xmx<size>M, in our case we set it to 4096MB == 4 GB. It depends on your station size.
   
   

Messages throughput

The number of messages per second is one of the main indicator to measure the performance. It depends on several factors:

• The IoT Hub plan tier (S1, S2, B1, B2...)
• The number of units
• The machine CPU
• The number of messages thread option in the connector
• The internet speed
• etc.

This is below an example of a station running 1,600 device and 32,000 control points which change every 2 minutes. It runs on an i7 cpu 2 core 4 vcpus ,100 Mbps internet speed, and 100 threads. It's sending roughly 18K messages per minute.

Number of devices vs Number of points per device

To enable the Niagara station to connect and subscribe to messages from IoT Hub, the connector uses and maintains a connection per device. Therefore, the connector needs to keep track of all the client connections in memory.

It affects the performance when you deal with a large number of device and a small memory heap. All the points of a particular device use the corresponding device connection to send its value.

• If you use a lot of devices and a small number of points per device it may drain memory
• At the opposite using few devices and a lot of points per device may affect the messages throughput performance

We recommend to keep a good ratio as shown in the example below. Imagine to have 1,000 control points: how many devices can you use and how many points per device?

• Example 1: 1,000 device and 1 point/device, this means the station has to create and reserve memory for 1,000 devices client connection. It consumes more memory but it will send a lot of messages because the connection is used by 1 point.
• Example 2: 1 device 1,000 points/device, this will use 1 device client. The memory will be ok. But the connection will be used by 1,000 points at the same time which may slow the process.
• Example 3: 50 device 20 points/device, this will use 50 connections and 20 points will share the same connection which is the perfect use case.
  

Keep in mind, this is just a demonstration example. In a real scenario you may have 50,000 control points where you need need to use 1,000 device and 50 points/device or 500 devices and 100 points/device.

Conclusion:

• The more devices you have the more memory you need.
• The more points per device you have the more messages threads and the more cpu power you need.
  
  

IoT Hub Quota and limits

Unfortunately IoT Hub allows only 20 modules (i.e. points in Niagara) per device. This is a limit we can't change (yet). By default the IoT Hub connector creates a module for each Niagara point (to leverage on the module twin feature). You can disable this functionality in the btibIoTHubConnector to go beyond this limitations of 20 points per device. It simply doesn't create any module.

There is also a quota applied on IoT Hub that limits the number of messages, number of connections/sec, number of registry operation/sec etc... so before create your IoT Hub, make sure to check the IoT Hub quota page at this link https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling