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
- 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 中文论坛