Facing time delay when send a first request to call Eikon Data API?

Hi,
I noticed that if I send a 1st request (with API key), it takes a bit longer than when I send a subsequent request. I presume there is some delay in authentication initially. In order to improve user experience, should I send a dummy request maybe when a user starts filling inputs so that their requests are processed a bit faster?
Please provide the suggested way?
Thank You,
Priya
Best Answer
-
Hello @priyanka,
Personally, I would not send any dummy requests for the purpose of speed up or to improve user experience.
The session is initiated once, then multiple requests are issued.
The user knows when they have started the app, so it is not unexpected for them.
Different requests also can take unequal amount of time, so this will not guarantee all requests very quick.
Plus this request will count toward EIKON DATA API USAGE AND LIMITS so if, for some reason, the user decides to rapidly restart the app repeatedly, dummy requests can potentially be generated on every restart and that can lead to hitting limits, which would be obviously undesirable.
Depending on what you run and what you observe, it may be additionally useful to test, if the startup of Eikon session from Eikon Data API is the only initialization happening and contributing to the perceived delay. Sometimes environments, such as Jupiter notebook, also introduce some additional overhead, so running "naked" python command line may be a clean test, and may allow you to better understand the full nature of the delay.
0
Answers
-
Hi @priyanka
when you say 'I send a 1st request (with API key) ' - I assume that means when you call set_app_key('appkey') ?
This call is a not a 'request' as such - the set_app_key() call is to establish a connection/session from your Python script with the locally running instance of Eikon. Therefore, yes the set_app_key call will take a moment whilst the connection/session is established.
Once the session is established, the time taken for the response to other calls such as get_data etc will depend on the type of request as explained by my colleague Zoya above.
In this regards, you can call set_app_key early on in your script e.g. at startup, so the connection is ready for when the user starts requesting data via the inputs.
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
- 685 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
- 252 ETA
- 556 WebSocket API
- 38 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
- 652 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
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 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 中文论坛