Java TREP UPA API - Choosing an Optimal Buffer SIze

arvnar2407

Hi, my application is using the Java UPA API and requesting data from RWF. I have a large subscription list (~400k) and request data in batches of 2048. I have noticed that with such a large list of subscription, the subscription requests drop some symbols in random every time and end up subscribing to a lesser number of symbols. (~370k)

On Tweaking and increasing the buffer sizes, such as below :

guaranteedOutputBuffers(512);

sysSendBufSize(1024*1024*32);

sysRecvBufSize(1024*1024*32);

numInputBuffers(256);

the application reached a stable state where it does not drop requests.

Is there an optimal way to choose the buffer size so that it can handle future increase in subscription lists?

Jirapongse

@arvnar2407

@pratik.p.mehta

SysRecvBufSize and SysSendBufSize control the underlying TCP send and receive buffers of system. They are related to TCP sliding Window which could affect maximum Bandwidth. These settings are for the underlying socket layer. The guideline is to set the receive buffer to match or exceed the send buffer of the source application.

GuaranteedOutputBuffers and NumInputBuffers are used in the UPA (ETA) layer.

GuaranteedOutputBuffers - Specifies the number of available buffers per channel. It is pre-allocated up front regardless of the client or server side. Trade-offs are memory footprint, especially on a server where there are many connections and each has all of this configured and allocated upfront.

NumInputBuffers - Specifies the number of sequential input buffers to allocate for reading data into. This controls the maximum number of bytes that can be handled with a single network read operation. This will more or less correlate to how fast we can pull in data from a full SysRecvBuf from the OS.

The GuarunteedOutputBuffer, SysRecvBufSize, and SysSendBufSize can be changed via the Channel.ioctl method.

I think there is no ideal setting for all consumers. It depends on the behavior of the application.

In this case, I assume that the application may send a lot of subscriptions that the API or TREP is unable to handle requests on time. Therefore, the approach is implementing subscription throttle in the application. For example, the application will not send the next batch request until all responses of the previous batch request are received, or the application can use a timer to send batch requests.