Datascope select asynchronous requests best practice

david.p.newman

Given that the datascope select api typically has a rate limit duration of 60 seconds, why would I have a wait time of less than 60 seconds on an asynchronous request, given that the request will be returned as soon as a result is available anyway?

Take the following example, an asynchronous request takes exactly 45 seconds to complete. If I have a wait time (default) of 30 seconds, then I will make 2 requests to the api within the 45 second period. However, if I have a wait time of 60 seconds, I will only make 1 request. In both cases, I will still receive the response within 45 seconds.

I feel that I must be missing something here, so would appreciate some info on this. Thanks.

Find more posts tagged with

asynchronous

datascope-select

#product

Accepted answers

Gurpreet

Hi @david.p.newman,

You are correct that the server will respond as soon as the data is ready. So what are the disadvantages of using extremely long timeouts in the requests:

1. The networking modules will block the code execution until the timeout period or a response is received. This can be circumvented by use of asynchronous IO libraries.

2. The network connection without traffic may be dropped by intermediaries like routers and firewalls, thereby loosing the response.

A timeout of 60 or 120 seconds is a good balance for long running queries.

All comments

Jirapongse

@david.p.newman

Thank you for reaching out to us.

I assume that you already knew that the wait time is configurable via the HTTP header.

Prefer: respond-async, wait=120

For more information, please refer to the DSS Key Mechanism document.

As far as I know, the extraction time is varied due to many factors, such as the number of instruments, the number of content fields, the data and time range, and server load. It should not be exactly 45 seconds for every request.

You need to adjust it according to your requirement. You can also refer to the LSEG DataScope Select Best Practices & Fair Usage Policy document.

david.p.newman

Thanks for the reply. Yes, I am aware of the wait=120 and I have read the documentation (although it's possible I've missed something!).

However, as per my example, I cannot comprehend why I would ever have a wait time of less than 60 seconds, given that the api will respond as soon as a response is ready. I guess one reason might be if my local process itself is asynchronous and I don't want to wait 60 seconds for a response. I guess my point is really that the advantage of having a wait time or more than 60 seconds, is that I don't "waste" a request from my quota, in the event that the response takes longer than the wait time.

Gurpreet

Hi @david.p.newman,

You are correct that the server will respond as soon as the data is ready. So what are the disadvantages of using extremely long timeouts in the requests:

1. The networking modules will block the code execution until the timeout period or a response is received. This can be circumvented by use of asynchronous IO libraries.

2. The network connection without traffic may be dropped by intermediaries like routers and firewalls, thereby loosing the response.

A timeout of 60 or 120 seconds is a good balance for long running queries.

EXPLORE OUR SITES