There are no hard limits on the number of data points or the update rates for the data in DataHub program. More data points require more memory, and more updates require more CPU. Different protocols require different amounts of CPU and memory.
The DataHub program imposes a limit of 128 MB on the length of an individual data point value. Very large values will take some time to be transmitted over a network, and can impose a large CPU and memory burden. If you intend to share data with Linux computers through a custom connection, the limit is 128,000 bytes. Please see Point Size Limits for more information.
The minimum hardware needed to run a DataHub instance depends on the number of data points, update rates, and other factors. This makes it difficult to determine in advance what hardware will be needed for any given system. At the very least, for 100 data points updating 10 times per second with one server and one client connecting by any supported protocol, any modern computer capable of running Windows is sufficient. For larger systems, you will need to test, which can be done by downloading free DataHub demo software from our website.
The total throughput of a running DataHub instance will depend on the total load, not just the input rate. If the DataHub instance is receiving 10,000 point changes per second, and there is 1 client connection, that will count as 10,000 point changes per second. If there are 5 client connections receiving that data, that becomes effectively 50,000 total changes per second being processed.
There are no hard limits on the number of data items or data updates per domain.
Configuring the DataHub Event Log to log to disk has a big impact on performance. If you are seeing slow performance, try disabling logging to disk.
Both the 32-bit and 64-bit versions of DataHub software will run at approximately the same speed, and will use the same number of processor cores.
The 32-bit version will run on 32-bit Windows or 64-bit Windows. It is limited to approximately 1.5 GB of total memory. It is more compatible with OPC programs, which are almost all 32-bit.
The 64-bit version will only run on 64-bit Windows, and it has no memory limit.
If you are using the Database feature (ODBC database connectivity) the bit depth of the ODBC driver must match the bit depth of the DataHub executable. Your choice of DataHub bit depth may be limited by the available ODBC drivers for your database.
If you are accessing an OPC Classic in-process server, the bit depth of the DataHub executable must match the bit depth of the OPC server. The bit depths of the DataHub executable and the OPC Classic server executable do not need to match for an out-of-process OPC server.
In general, we recommend using the 32-bit version if you are accessing OPC Classic applications, unless you need the extra memory capacity of the 64-bit version.
There are no hard limits on the number of OPC tags or values that can be sent or received by OPC servers or clients. The number of data points and throughput is limited by memory and CPU. In test situations for OPC DA on reasonably modern hardware we have achieved over 100,000 data point changes per second. The OPC client and server code in the DataHub program automatically combines multiple point changes into a single OPC message whenever it can. Generally, OPC DA is faster than OPC UA on the same machine, and DHTP (DataHub tunnelling) is the fastest way to network OPC data. OPC UA requires much more memory than other protocols.
There are no hard limits on the number of points for the Redundancy feature. It is limited by memory and CPU. The total data point count is the sum of the data points counts in each domain. The number of domains is the total of all input and output domains for all redundant connections. For example, a single redundant configuration has 2 inputs and 1 output, for a total of 3, requiring enough memory for 3 times the number of points as are in one of the source domains.
There are no hard limits on the number of points that can be bridged. The Bridging feature is built directly into the data path of the point change-handling code of the DataHub program, so it is as efficient as a normal point change. CPU load is based on point changes, while the memory load is based on the number of points, plus a small amount for the Bridging configuration itself.
Our testing of the Database Write (logging) feature on MS-SQL and MySQL shows that typically the database server can handle up to about 1,000 transactions per second on a reasonably fast computer. The limiting factor is the speed of the database server. We have tested DataHub software with Times Ten database, which is faster than a typical SQL database. On that, a DataHub instance can send about 10,000 transactions per second. The limiting factor in that case is the speed of the DataHub program.
OPC A&E conditions contain many individual properties. When you select the option to , it will result in multiplying the number of A&E conditions by 50 or more. So, an A&E server with 1000 conditions could multiply to 50,000 data points or more when that option is selected.
The per-point transmission size for DHTP is approximately 60 bytes plus the length of the data point name. The tag name is UTF-8 encoded, so for names that can be represented in the 7-bit ASCII character set, that is 1 byte per character. Where possible the DataHub program combines point transmissions into single TCP/IP packets to reduce TCP header overhead, up to 1 kB in size.
The DataHub program does not transmit all points. It transmits only those that have changed since the previous scan. Consequently, the size of an OPC scan group does not matter. The important calculation is how many points within the scan group change with each scan. You can see the point transmission rate in the DataHub "View Connections" window.
If the data transmission is write-only then there is no acknowledgement back from the server. If the data transmission is read/write then the server will send back an equivalent message for every point change, effectively doubling the bandwidth requirement.
There is some overhead in SSL when the connection is established—typically around 10 kB. Once the connection is established there is about a 2% increase in bandwidth. The biggest overhead is when establishing the connection, not during data transmission.
Tunneling takes advantage of the TCP/IP buffer to smooth changes in network speed. The buffer is set to 8 kB, which roughly translates into about 100 data point messages. If this buffer fills, you will see that manifest in the DataHub Connection Viewer as an increment to the "Blocked" counter for the connection. If a data point value changes while the connection is blocked, the oldest value for that point is dropped, and the Dropped counter in the connection viewer will increment. If the Dropped counter remains at zero then all data point changes are successfully being transmitted through the tunnel. If the Blocked counter is increasing then the average data rate is faster than the network can handle.
There are no hard limits in the MQTT Broker on the number of connections or topics. The message size limit follows the MQTT specification, which is 256 MB. For values that will be stored in a DataHub instance, that maximum is 128 MB. Large messages will result in large RAM use, as each message is stored a minimum of twice (once in the DataHub engine and once in the MQTT Broker), and will be copied during transmission, possibly resulting temporarily in several more copies.