Non-interactive provider performance
I have a task to develop Reuters provider and I am now facing a choice between interactive and non-interactive one.
From what I know the NIProvider is fully sufficient for me. The only concern I have is of course the performance/throughput.
What would be the best choice from your opinion?
If you say that the “classical” provider has a better performance that I have to rethink my concept.
Best Answer
-
I think something is being overlooked here.
This discussion depends on how you define "performance". In a like-for-like discussion there are three things to consider:
The amount of work the Provider has to do is probably the same as they both have to do the same amount of rsslWrites assuming they are both publishing the same items (*).
The amount of work the ADS/ADH has to do. I'm not sure this is the same in both cases but I wouldn't really know who's on top there ... or if indeed there's any noticeable difference.
The amount of work for the consumer. I'm pretty sure this is exactly the same.
The devil is in the details. Note the little (*). The Interactive Provider only has to publish items where there are active listeners while the Non-Interactive Provider will have to publish everything always. This is the essential difference between Interactive and Non-Interactive. At the end of the day this can potentially translate into a huge performance benefit for the Interactive Provider. As long as the demand varies in the sense that not all data items are in demand all of the time then the Interactive Provider will typically win I would say, simply because it can concentrate on lesser amount of work.
With the Interactive Provider you also avoid spamming the infrastructure with unnecessary data so it may also be more cost effective as you only have to dimension your infrastructure after the "demand" rather than the "supply".
0
Answers
-
Due to TREP internal details an interactive provider performs significantly better than a non-interactive provider. Reference numbers for non-interactive, 800k updates/second for UPA/C compared to 1.6M updates/second for interactive. For RFA the numbers are not so significantly different, 220k/s vs. 240k/s. Obviously numbers will vary.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 684 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 249 ETA
- 554 WebSocket API
- 37 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 643 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 192 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛