When Broker Server uses a single TCP/IP connection for Broker to Broker communication, there can be delays in message transmission in high-bandwidth and high-latency networks (WAN). These delays occur because a single TCP/IP connection cannot scale up to fully use the available bandwidth.

To deal with these delays, Broker Server can be configured for streaming and/or remote Broker parallel channels.

Streaming improves the performance of Broker Server when the servers are connected across high-latency networks. When steaming is not enabled between Broker Servers, the messages are transferred using the request/reply mode. In this situation, one batch of documents are sent, and the subsequent transfer happens only after receiving an acknowledgement message from the receiver. Hence, the performance is affected due to the round-trip time (RTT). However, when you configure streaming in Broker Servers, documents are sent in multiple batches without waiting for an acknowledgement from the receiver, thereby improving the performance of the server.

Parallel channels enable a Broker Server to use more than one TCP/IP socket for Broker to Broker communication, thus increasing throughput at the connection level. Test results show linear increase in message throughput when a remote Broker is configured for 5 channels (default) and 10 channels.

When you configure Broker Server for streaming, the performance of the server improves while routing small documents. When you configure parallel channels in Broker Server, the performance of the server improves while routing large documents. A combination of parallel channels with streaming improves performance of the server in case of small and large documents.