Decoding time for EMA
Not sure if you have the measurement about the time used for decoding the EMA message in the EMA consumer application? e.g. time when entering into the function onUpdateMsg() till the process is done, statistics like Min/Max/Median/Average...
Best Answer
-
Hi @otto.to.1
The reason for using a View was to reduce the number of fields you receive in Refresh and Updates, therefore it seems quite odd that it would take longer to process messages with fewer Fields than messages with more fields.
Therefore, I would be interested in more detail so we can get a better understanding of what you are observing?
- How exactly are you measuring the latency?
- What are you doing with the decoded payload - are you performing some intensive activity like writing to a database or similar?
- What time unit are the min/max/median values above?
- How long did it take to receive the 45000 updates?
- How many times did you run each test?
- how many instruments were you subscribing?
- If the tests with and without View were at the same time of day?
- Are you connecting to a local ADS server or connecting to one of our Cloud Servers? If you are not sure please provide the hostname you connect to.
- Are you able to observe similar latency by using one of our simpler examples e.g 370__MarketPrice__Batch with minimal changes for timestamping and simply redirecting the output to a file rather than screen - i.e. not doing your current payload handling?
Also, note that running a test during a busy market activity period may not provide the same results as running at a quiet time. One example I recently came across, the user was connected to onsite servers and during certain peak activity periods their servers maximum bandwidth was breached, messages were backlogged and as a result, the application received messages which were several seconds old as the backlog slowly cleared.
Also, I cannot determine your organisation name your non-corporate email address and therefore cannot confirm if you have access to RDC - our Premium Developer support service. This is important as your particular case may require some deeper offline investigation. If you can add an additional private comment with your details that would be helpful.
0
Answers
-
Hi @otto.to.1
As you may be aware, OmmConsumerClient class provides callback interfaces to pass received messages. It is your application's responsibility to implement an application client class inheriting from OmmConsumerClient and override callback methods it desires to use for processing the Refresh, Update, StatusMsg etc.
Therefore, the amount of time taken to decode a message in your event handlers such as onUpdateMsg() will depend on your implementation within these methods as well things like the number of fields you need to decode on each invocation.
These functions are executed on the API thread, so If you want to reduce the amount of time spent within these functions - you can take various measures - e.g.:
- Use Dynamic View to reduce the number of fields you request from the server
- create additional worker threads to do some of the heavy processing - you can clone the UpdateMsg and pass it into the worker thread functions.
For more information on Dynamic views please refer to the example 360 MarketPrice_View provided with the Refintiv Realtime SDK (previously known as ElektronSDK)
1 -
It becomes worse after switching to Dynamic view. The latency for decoding is nearly doubled in this mode:
The total number of updates: 45000
median: 80
min is: 11
max is: 1396543I use the Dynamic view in this way:
Consumer.registerClient( ReqMsg().serviceName("user").payload(ElementList().addArray(":ItemList",zArrayInterest).addArray("ENAME_VIEW_TYPE", ema_access::OmmArray().addInt(178).addInt(6).addInt(14).addInt(131).addInt(44).addInt(3900).addInt(8665).addInt(8666).addInt(8667).addInt(13432).addInt(4756).addInt(4757).addInt(12840).addInt(4345).addInt(3854).addInt(14266).addInt(5).addInt(22).addInt(25).addInt(30).addInt(31).addInt(118).addInt(3264).addInt(6614).addInt(6577).addInt(3855).addInt(14265).complete()).complete()), *this);
While without using dynamic view:
The total number of updates: 45000
median: 48
min is: 4
max is: 726Originally I register the consumer like this:
Consumer.registerClient( ema_access::ReqMsg().serviceName("user").payload(ElementList().addArray(":ItemList",zArrayInterest).complete()), *this);
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛