Performance Issue with Delay in Batch Request Processing In EMA API

log.txtI am currently conducting a performance test using the EMA API and have encountered an issue with the timing of batch request processing. My test involves sending 40 batch requests simultaneously, each containing 22 symbols.
I received all 40 status messages indicating "Close/OK/None/Stream closed for batch" at 16:30:06.xxx.However, I observed that the last outgoing reactor message(the request message) was sent to the EMA API at 16:30:10, which is 4 seconds later than the status messages. and the last incoming message(the refresh message) was received at 16:30:11. This delay seems to indicate that not all request messages are being sent simultaneously, resulting in a 5-second lag in receiving the final refresh message. My goal is to optimize this process so that all request messages are sent without this lag, allowing for earlier reception of refresh messages.
Are there specific settings within the EMA configuration that I can modify to enhance the performance and reduce the delay in message processing.

I have additional observation from the log files. At the start, the application sends about 10-20 requests to the EMA API. After receiving the first response(the refresh message), the application shifts to a pattern of sending a request and then processing a response before sending the next.

I'm using EMA JAVA 3.7.2.

Find more posts tagged with

java

elektron

ema-api

#technology

#product

Accepted answers

Jirapongse

@xinjames.chen

Thank you for reaching out to us.

I assume that each batch contains the same items and you are using snapshot requests.

Typically, EMA supports watch list and fanout so it sends one request message for duplicated subscriptions. Then, it can fanout the retrieves messages to all subscriptions.

However, according to the log, some subscriptions may be overlapped. For example, the application may register the same item after the request message was sent. Therefore, EMA will sent another request after receiving the refresh message, as shown below.

<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REFRESH domainType="MARKET_PRICE" streamId="8" containerType="FIELD_LIST" flags="0x1FA (HAS_PERM_DATA|HAS_MSG_KEY|HAS_SEQ_NUM|SOLICITED|REFRESH_COMPLETE|HAS_QOS|CLEAR_CACHE)" groupId="0" seqNum="29168" permData="0301 0184 C0" Qos: Realtime/TickByTick/Static - timeInfo: 0 - rateInfo: 0 State: Non-streaming/Ok/None - text: "*All is well" dataSize="141">
    <key flags="0x07 (HAS_SERVICE_ID|HAS_NAME|HAS_NAME_TYPE)" serviceId="257" name="AFN.TO" nameType="1"/>
    <dataBody>
        <fieldList flags="0x09 (HAS_FIELD_LIST_INFO|HAS_STANDARD_DATA)" fieldListNum="0" dictionaryId="1">
            <fieldEntry fieldId="6" data="094E 9530"/>
...
        </fieldList>
    </dataBody>
</REFRESH>


<!-- Outgoing Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/10.57.137.133:64548 remote=/ 10.215.149.140:14002] -->
<!-- Wed Nov 29 18:57:32 EST 2023 -->


<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REQUEST domainType="MARKET_PRICE" streamId="8" containerType="ELEMENT_LIST" flags="0x442 (HAS_PRIORITY|HAS_QOS|HAS_VIEW)" Qos: Realtime/TickByTick/Static - timeInfo: 0 - rateInfo: 0 priorityClass="1" priorityCount="1" dataSize="80">
    <key flags="0x03 (HAS_SERVICE_ID|HAS_NAME)" serviceId="257" name="AFN.TO"/>
    <dataBody>
        <elementList flags="0x08 (HAS_STANDARD_DATA)">
            <elementEntry name=":ViewType" dataType="UINT" data="1"/>
...

I checked the EMA configurations and was unable to find any configurations that can control the number of request messages sent by the API.

If you would like to determine the performance of the API, you can refer to the EMA Performance Tools (\Java\Ema\PerfTools) in the package.

All comments

Jirapongse

@xinjames.chen

Thank you for reaching out to us.

I assume that each batch contains the same items and you are using snapshot requests.

Typically, EMA supports watch list and fanout so it sends one request message for duplicated subscriptions. Then, it can fanout the retrieves messages to all subscriptions.

<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REFRESH domainType="MARKET_PRICE" streamId="8" containerType="FIELD_LIST" flags="0x1FA (HAS_PERM_DATA|HAS_MSG_KEY|HAS_SEQ_NUM|SOLICITED|REFRESH_COMPLETE|HAS_QOS|CLEAR_CACHE)" groupId="0" seqNum="29168" permData="0301 0184 C0" Qos: Realtime/TickByTick/Static - timeInfo: 0 - rateInfo: 0 State: Non-streaming/Ok/None - text: "*All is well" dataSize="141">
    <key flags="0x07 (HAS_SERVICE_ID|HAS_NAME|HAS_NAME_TYPE)" serviceId="257" name="AFN.TO" nameType="1"/>
    <dataBody>
        <fieldList flags="0x09 (HAS_FIELD_LIST_INFO|HAS_STANDARD_DATA)" fieldListNum="0" dictionaryId="1">
            <fieldEntry fieldId="6" data="094E 9530"/>
...
        </fieldList>
    </dataBody>
</REFRESH>


<!-- Outgoing Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/10.57.137.133:64548 remote=/ 10.215.149.140:14002] -->
<!-- Wed Nov 29 18:57:32 EST 2023 -->


<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<REQUEST domainType="MARKET_PRICE" streamId="8" containerType="ELEMENT_LIST" flags="0x442 (HAS_PRIORITY|HAS_QOS|HAS_VIEW)" Qos: Realtime/TickByTick/Static - timeInfo: 0 - rateInfo: 0 priorityClass="1" priorityCount="1" dataSize="80">
    <key flags="0x03 (HAS_SERVICE_ID|HAS_NAME)" serviceId="257" name="AFN.TO"/>
    <dataBody>
        <elementList flags="0x08 (HAS_STANDARD_DATA)">
            <elementEntry name=":ViewType" dataType="UINT" data="1"/>
...

I checked the EMA configurations and was unable to find any configurations that can control the number of request messages sent by the API.

If you would like to determine the performance of the API, you can refer to the EMA Performance Tools (\Java\Ema\PerfTools) in the package.

xinjames.chen

Thanks for quick response. Based on the guidance about EMA's handling of duplicated subscriptions and fanout, I conducted an additional test to further investigate the issue.

I send 100 snapshot batch request, each containing only one symbol. 50 request were for BMO.TO and another 50 for TD.TO.

Observation in Logs:

The last status message indicating "Stream closed for batch" was logged at 08:02:20.809

The first refresh message was received at 08:02.20:822

The last refresh message was received at 08:02:25

The last outgoing reactor message (request message) was sent at 08:02:25

I observed a 5 second delay between the last "Stream closed for batch" status message and the sending of the last outgoing reactor request message. I expected the outgoing request messages to be send immediately after receiving the "Stream closed for batch" message, not 5 seconds later.

What could be causing this delay in sending out the request messages?

However, Sent one batch request containing 200 items. Notably, all outgoing request messages for this large batch were sent at the beginning, and the entire process was completed within 500 milliseconds

log1.txt log2.txt

xinjames.chen

log2.txt

upload log file again

Jirapongse

@xinjames.chen

Thank you for the information.

This forum is aimed at answering "how to" types of questions about using Refinitiv APIs. To verify the behavior in the API regarding performance, please contact the API support team direclty via Contact Premium Support.

However, you need to be a RDC named user in order to access Contact Premium Support. You can contact your Refinitiv account team or sales team direclty for more information regarding a RDC subscription (Refinitiv Developer Connect).

Otherewise, you can raise this issue to the development team directly via GitHub.

EXPLORE OUR SITES