I am not sure if this is a limitation connected to the OMF, WebAPI, or https itself, but in the manual it is given that the maximum message size is 192KB. I am aware that compression is recommended and applied by default by the adapters. For the rest of the suggestion read "192KB" as "192KB before compression is applied, which is applied by default by adapters and recommended".
https://docs.aveva.com/bundle/omf/page/http-behaviors.html
https://docs.aveva.com/bundle/aveva-adapter-opc-ua/page/main/shared-content/configuration/egress-endpoints.html
The adapter manual further states that the next message is not transmitted until the previous one has been accepted ("Types, containers, and data are egressed as long as the destination continues to respond to HTTP requests"), which implies to me that the adapter will wait for a response. That means that the maximum throughput on a channel is limited by the latency for the 192KB to travel from the adapter to the OMF endpoint, and then for the response to get back to the adapter. In case of a VSAT type connection where the latency can be 500ms to a second, the maximum throughput of the channel will be 192KBps or 384KBps. In practice I have seen as low as 6,000B/sec in windows Resource Monitor, when I know through e.g. copy large files that the available bandwidth is much higher, but the latency is pretty bad.
If the expectation is that adapters are to replace connectors, then increasing the data throughput rate is critical.
If (as originally advertised) the adapters are designed to work at "the edge" where connectivity is sub-optimal, then increasing throughput to make use of available bandwidth is actually part of the core mission.
I think if the limit is not related to HTTPS, but is related to WebAPI or OMF then the 192KB limit should be increased as much as possible, ideally into the MB range.
