question

Upvotes
Accepted
3 0 0 1

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

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?

treprfarfa-apiperformance
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.

Upvote
Accepted
25.3k 87 12 25

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

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.

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?

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!


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 ?

Show more comments
Upvotes
9.6k 10 7 7

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.


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.

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.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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