RFA JAVA API Performace (wrt numbers of GC and compared to RFA C++)

sishubha

We are in favor of choosing the RFA JAVA API. Is the API efficiently built in terms of garbage it generates? Since our application is latency sensitive, we expect no major GC cycles due to garbage from RFA JAVA API.

Also, Is there a recommended API to choose between RFA JAVA and RFA C++ APIs due to performance benefits.?

Can you please have your opinion?

umer.nalla

Hi @sishubha

You may find the following document on MyRefinitiv useful

TREP APIs Performance Test Results - February 2014

It contains comparative performance figures for RFA versions 7.5 and should provide an idea of the differences in performance between RFA Java and C++

The actual real-life differences can vary based on a number of factors including but not limited to your network, infra components, the volatility of our instruments and size of updates etc

pimchaya.wongrukun01

Hello @sishubha

According to API Concept Guide page 13 in Table 2: API Performance Comparison:

Transport API(ETA) is very high throughput, lowest latency, lowest memory footprint as shown in the table above.

ETA(Elektron Transport API) is one of Elektron API family. ETA is a transport layer API, open source, for the development of high performance and low latency applications. It is available in C and Java edition. For more details, please refer to Elektron API family page.

sishubha

Thanks for the response.

However, the product in our case is "Reuters_Matching_Data_Feed_Direct" which only allows the use of RFA APIs(JAVA/C++) to connect to the MDFD server.

Thus It would be great if you can be more specific about the performace of RFA JAVA API in terms of Latency/Garbage collection and in comparision to RFA C++ API.

sishubha

Thanks @Umer_Nalla, These results are for 2014, which is now more than 6 years old. I guess test results for a recent date are not available otherwise you would have provided that. So I'll rather ask, does the RFA APIs more or less perform similarly in your opinion? Or does a particular API might have become more performant in recent times?

umer.nalla

Hi @sishubha

There has been some optimisations and improvements to the RFA codebase until a few years ago - but not aware of any major performance improvements since 2014.

This will be a subjective answer as I have seen differences in performance with the different customers I have worked with - however, based on personal experience and in line with expectations, the RFA C++ version has shown to be slight to considerably more performant than the RFA Java version - based on the usage scenario and other factors mentioned above.

For best performance, you would really need to use ETA or EMA. However, you mentioned the restriction is due to MDFD. Feel free to encourage the MDFD team to offer EMA and ETA support!

sishubha

Thanks @Umer_Nalla for the quick response.
Lastly I would ask if you have encountered complaints from clients regarding the RFA Java API generating too much garbage or high number of Java GC cycles creating a problem ?

umer.nalla

Hi @sishubha

I am not sure complaints is the right word - there have been issues for example when a developer is not using the API in the most optimal manner e.g. creating too many objects, rather than clearing them and re-using them. Certainly have helped guide (and shock!) a few developers who by just changing a few lines of code - i.e. to reuse an RFA object rather and create one have seen dramatic improvements in performance and memory usage.

sishubha

Thanks Umer. Assuming the client side code utilize the RFA API in optimized manner (reusing RFA objects etc), RFA API won't in itself generate Garbage issues. Am I right in assuming this?

umer.nalla

Hi @sishubha

Unfortunately, I cannot give any blanket assurances that there will be 'no issues'. We are talking about a realtime streaming API with a potentially high throughput of data.

As it is a Java based API there is always the possibility of garbage collection related issues - however, we did our best at the time to optimise the design of the API and minimise the impact of GC on the performance.

All I can say is that RFA Java is used in many financial organisations, in hundreds of applications for consuming large volumes realtime data with relatively high throughput being achieved. Those who needed to support higher throughput typically used RFA C++ or our UPA API (now called ETA).

My understanding from the dev team is that the EMA + ETA APIs are better optimised - we applied a lot of our learning from RFA to improve this aspect of EMA/ETA.