Calls to TRTH Service Appear Slow
Attached is sample code, which various timing checkpoints. To reach the first checkpoint takes 6.65 seconds, to reach the second point takes another 22.4 seconds, and to reach the final checkpoint takes another 30 seconds. In total this takes 59.33 seconds to make a request for a time-sales file.
I'm confused why the call is taking this much time to simply make a request, without waiting for any data to come back. In the old thomson reuters service a comparable call would come back basically in a second ... i.e. there is no work to be done, this is just a request to run a report.
Can you let me know if this is the expected behavior?
Best Answer
-
In a nutshell: 30 seconds to submit an extraction request is an expected behavior.
In detail: you ask why the call is taking this much time to simply make a request without waiting for any data to come back. I looked at your code:
- Between checkpoints 0 and 1 is the actual POST extraction request. It has header "Prefer":"respond-async; wait=0". Due to wait=0 the request will return without waiting.
- Between checkpoints 1 and 2 is a GET to the location URL, which is actually the first wait for the extraction to complete, this is not part of the extraction request submission. As the "Prefer" header does not contain wait=, the default wait time of 30 seconds applies, i.e. this call will return when the extraction is complete, or after 30 seconds, whatever comes first.
- The extraction status is tested with the GET location URL call immediately after sending the extraction request. This is not recommended, because an extraction for 4 days of trades will never return data so fast (Jirapongse's test extraction took ~90 secs), so the immediate GET just adds to the server load but will not ensure faster delivery.
I ran your code 3 times, got the following timing values (output concatenated to gain space):
First run:
check point #0 --- 3.707199811935425 seconds --- 202
check point #1 --- 13.806599855422974 seconds --- response status = 202
check point #2 --- 44.50179982185364 seconds ---Second run:
check point #0 --- 0.9170002937316895 seconds --- 202
check point #1 --- 6.430200099945068 seconds --- response status = 202
check point #2 --- 37.169400215148926 seconds ---Third run:
check point #0 --- 0.7949995994567871 seconds --- 202
check point #1 --- 6.064199686050415 seconds --- response status = 202
check point #2 --- 36.68839955329895 seconds ---Conclusions:
- The POST extraction request took ~7 seconds (mean value). Maybe you expected this to return faster due to the wait=0 header, but the observed timing is in the expected range.
- The GET request to the location URL took ~30 seconds. As the response status was 202 (extraction not complete) this is absolutely normal, because this call returns when the extraction is complete, or after 30 seconds, whatever comes first.
Recommendations:
- Remove wait=0 from the POST header.
- For more information see the help page on async mechanisms.
2
Answers
-
I used the same request to perform the extraction and it took more than 1 minute for the extraction to be completed.
After the extraction is completed, you will get the Notes which contains information about extraction process.
@{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#RawExtractionResults/$entity","JobId":"0x05fe6d49c6ab3036","Notes":["Extraction Services Version 11.2.38072 (5e4c6f24f018), Built Dec 11 2017 21:00:31
...
Extraction ID: 2000000010274682Schedule: 0x05fe6d49c6ab3036 (ID = 0x0000000000000000)
Input List (1 items): (ID = 0x05fe6d49c6ab3036)Created: 12/20/2017 14:11:24 Last Modified: 12/20/2017 14:11:24
...
Schedule Time: 12/20/2017 14:09:53
Processing started at 12/20/2017 14:09:58
Processing completed successfully at 12/20/2017 14:11:27
Extraction finished at 12/20/2017 07:11:27 UTC, with servers: tm07n01, TRTH (77.111 secs)
...}You could verify to this Notes regarding how the extraction was processed.
0 -
I echo potential performance issue. It's much slower than V1. When I try to get intraday summary data, sometime it even hangs.
0
Categories
- All Categories
- 6 AHS
- 39 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 中文论坛