Calls to TRTH Service Appear Slow

noah.kauffman
noah.kauffman Explorer
in TRTH

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?

Tagged:

Best Answer

  • Christiaan Meihsl
    Christiaan Meihsl LSEG
    Answer ✓

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

Answers

  • Jirapongse
    Jirapongse ✭✭✭✭✭

    I used the same request to perform the extraction and it took more than 1 minute for the extraction to be completed.

    After the extraction is completed, you will get the Notes which contains information about extraction process.

    @{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#RawExtractionResults/$entity","JobId":"0x05fe6d49c6ab3036","Notes":["Extraction Services Version 11.2.38072 (5e4c6f24f018), Built Dec 11 2017 21:00:31
    ...
    Extraction ID: 2000000010274682Schedule: 0x05fe6d49c6ab3036 (ID = 0x0000000000000000)
    Input List (1 items): (ID = 0x05fe6d49c6ab3036)Created: 12/20/2017 14:11:24 Last Modified: 12/20/2017 14:11:24
    ...
    Schedule Time: 12/20/2017 14:09:53
    Processing started at 12/20/2017 14:09:58
    Processing completed successfully at 12/20/2017 14:11:27
    Extraction finished at 12/20/2017 07:11:27 UTC, with servers: tm07n01, TRTH (77.111 secs)
    ...}

    You could verify to this Notes regarding how the extraction was processed.

  • jim.yu
    jim.yu Explorer

    I echo potential performance issue. It's much slower than V1. When I try to get intraday summary data, sometime it even hangs.

Categories