Data Ingestion
When determining ThingWorx system requirements, it is important to consider how much data the platform will be expected to receive from edge devices.
The steps below can be used to estimate the expected writes per second (WPS) for each type of device, which can be added together to determine the total estimated ingestion load from all device types.
The rate of ingestion depends not only on the number of devices, but also the number of properties from each device, and the rate those properties change:
Number of Things (“Thingcount”): The number of Things (or devices, sensors, connections, modules, etc.) to be managed by ThingWorx. Thingcount affects many components, such as the required number of connection servers as well as platform memory requirements.
Properties per Thing: The number of values each Thing will send to ThingWorx.
Only use the estimated number of logged properties per Thing.
Persistent properties use a different thread pool than the value stream subsystem used for logged properties. Persistent properties are less likely to impact ingestion performance and reliability.
Transmission Frequency: This is often one of the largest factors in determining the database requirements for a ThingWorx solution.
Not all properties need to be logged at the same frequency. Carefully consider your business use case to avoid overuse of high-frequency properties with larger implementations than required.
To convert between per day (FD) and per second (FS), you can divide or multiply by 86,400 (the number of seconds in one day).
With these values, the total writes per second (WPS) can be determined as the sum of writes for each different type of property, for each type of Thing.
For example, if you have 100 Things (T) with the following logged properties:
10 properties (P1) which update once per minute (F1)
5 additional properties (P2) which update once per second (F2)
The calculation would be:
WPS = T × [(P1 × F1) + (P2 × F2)]
= 100 × [(10 × 1/60) + (5 × 1)]
≈ 100 × [0.17 + 5]
≈ 100 × 5.17
≈ 517 writes per second
In the simple scenario above, an extra-small ThingWorx system with a simple database, such as H2, should handle this load but would still not be advisable in a production environment.
Most real-world use cases will have multiple types of Things and higher Thing and property counts to consider.
Connection Servers are generally required to distribute workload from higher volumes of edge device connections. A maximum of 100,000 devices per Connection Server is typically recommended, but this number can vary based on the number of connections between each device and the ThingWorx Platform and the size of the messages being sent.
Specific sizing for Connection Servers can be found in the Connection Services Help Center.
Two examples involving these calculations are provided here.
Was this helpful?