First, you mentioned you have 18 connections with 30 16-bit words each at 50 milliseconds (20 samples per second). We’ve used the openHistorian in systems that archive data from hundreds of devices that provide ~20 signals at 30 samples per second. Matter of fact, openHistorian benchmarks have indicated that it is capable of archiving on the scale of millions of data points per second. The historian should be able to handle your data volume with no problem.
In regards to the HistorianInputQueue approach versus the OnNewMeasurements approach, I don’t think performance should be your primary concern. The difference between these two approaches would be that the HistorianInputQueue uses the SnapNetworkClient to send data over a socket whereas the input adapter is hosted within the openHistorian application itself. Therefore, the HistorianInputQueue has the obvious advantage of enabling you to host your custom code on another machine and send the data to the openHistorian over the network, and the input adapter has the advantage of bypassing the overhead of the socket connection, although I suspect the difference in performance is likely negligible. What may be less obvious is that the input adapter solution will provide the APIs to interact with the openHistorian configuration so you can apply the appropriate signal IDs to your measurements and then properly visualize them using the openHistorian web UI that Ritchie mentioned. The SnapNetworkClient bypasses the measurement routing mechanisms in openHistorian and writes measurements directly to the archive, which means that if you want to use the openHistorian web tools to access your data, you will have to synchronize configuration between your HistorianInputQueue app and the openHistorian database.
If your question was about whether to use the HistorianInputQueue within an input adapter to write measurements to the archive, I would obviously recommend against doing that since all it does is add the overhead of dealing with a socket-based connection. Instead, you should just call
OnNewMeasurements. The measurements can make their way to the archive via the routing mechanisms in the host environment.