RFA .NET excessive memory usage when subscribing to thousands of RIC codes
We are currently using RFA.NET 8.1.0 and we are seeing a drastic increase in our memory usage while subscribing to around thousands RICs. We've attempted to reduce the memory usage by making use of Dynamic Views to reduce the number of Field Entries we get back and we've moved our processing logic out of the ProcessEvent() method. We now write the events to an internal collection and read from that on a separate thread.
Our issue seems to be with the volume of RICs we're subscribing to. Is there a way we can improve our RAM usage and more efficiently handle all of the incoming market events for all of these RICs?
Best Answer
Answers
-
Hi
Some alternatives here:
- if acceptable use a conflated service so it updates only, for instance, once per second
- if acceptable request snaps in a loop, use a view field list to request only the fields needed, you might need to check the request period as it may take time to iterate over all instruments
- compute update frequency for all itens, the ones that update too fast go to a `request snap list`, for these you get snaps as described in the second item. The other itens continue as normal subscriptions.
- some applications try to update a GUI for every update then the GUI thread becomes the bottleneck. (same idea when application try to save market data to a Database).
Could you please reveal how many items are you trying to subscribe?
I have faced similar problems here with a project that tries to subscribe more than 10k itens.
I am trying to implement the mix approach snap+realtime combination as there is no conflated service available.
Another point is when you expand or not chains in your code as one chain ric can result in hundreds others being subscribed to.
0 -
Hi
Some alternatives here:
- if acceptable use a conflated service so it updates only, for instance, once per second
- if acceptable request snaps in a loop, use a view field list to request only the fields needed, you might need to check the request period as it may take time to iterate over all instruments
- compute update frequency for all itens, the ones that update too fast go to a `request snap list`, for these you get snaps as described in the second item. The other itens continue as normal subscriptions.
- some applications try to update a GUI for every update then the GUI thread becomes the bottleneck. (same idea when application try to save market data to a Database).
Could you please reveal how many items are you trying to subscribe?
I have faced similar problems here with a project that tries to subscribe more than 10k itens.
I am trying to implement the mix approach snap+realtime combination as there is no conflated service available.
Another point is when you expand or not chains in your code as one chain ric can result in hundreds others being subscribed to.
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛