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.

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.