question

Upvotes
Accepted
arvnar2407 avatar image
9 ●2 ●2 ●5

Java TREP UPA API - Choosing an Optimal Buffer SIze

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?

elektronrefinitiv-realtimeelektron-sdktrepjavabuffer
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

pratik.p.mehta avatar image pratik.p.mehta

@Refinitiv - could you please help understand what these 4 settings mean?guaranteedOutputBuffers, sysSendBufSize , sysRecvBufSize and numInputBuffers.

Which one applies to consumers and servers? So our application connects with TREP using UPA 8.0.0.L1.all.rrg version and as our subscription increases, we notice that the refresh messages get dropped OR we don't even subscribe.

As a consumer, what should be the ideal settings? or how can we dynamically set them?

Our applications run on Unix

1 Answer

Upvotes
Accepted
Jirapongse avatar image
47.4k ●111 ●44 ●60

@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.



1590466008326.png (80.9 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

pratik.p.mehta avatar image pratik.p.mehta

Thank you for the update, when you say "The guideline is to set the receive buffer to match or exceed the send buffer of the source application." In our use case, it will be the ADS host right? so if Application A is consuming data from ADS, so you suggest to ensure the receive buffer on Application A to match or exceed that of ADS?

pratik.p.mehta avatar image pratik.p.mehta pratik.p.mehta

Our ADS buffer sizes are around 64k

*ads*tcpRecvBufSize : 64240

*ads*tcpSendBufSize : 64240

I assume these numbers are in bytes

Jirapongse avatar image Jirapongse

Yes, it is the ADS host.

tcpRecvBufSize and tcpSendBufSize are in bytes.