Calls to TRTH Service Appear Slow

noah.kauffman

sample-code.txt

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?

Christiaan Meihsl

@noah.kauffman,

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.