@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.

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.

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.