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...
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?
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.
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.:
For more information on Dynamic views please refer to the example 360 MarketPrice_View provided with the Refintiv Realtime SDK (previously known as ElektronSDK)
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: 1396543
I 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: 45000median: 48 min is: 4max is: 726
Originally I register the consumer like this:
Consumer.registerClient( ema_access::ReqMsg().serviceName("user").payload(ElementList().addArray(":ItemList",zArrayInterest).complete()), *this);
