At market close we seem to be running out of performance. The messages arrive and the EMA API gives out. I have tried to move most processing onto other treads. But because of the GlobalBuffer some processing, i.e. copying has to be on the AppClient callback thread, becaue the FieldEntry objects are transient. Does changing the Channel NumInputBuffers SysRecvBufSize and HighWaterMark make any difference? If I change these what are good values to have?
3
●1 ●0 ●1
Elektron EMAConfig.xml Consumer Buffer tuning
@michael.chong
Thank you for your participation in the forum. Are any of the replies below satisfactory in resolving your query? If yes please click the 'Accept' text next to the reply that best answers your question. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.
Thanks,
-AHS
24.7k
●54 ●17 ●14
Hello @michael.chong
Does the application encounters the memory leak problem or the ADS log contains "Output threshold breached for <EMS login user> .." message? If so, it means the consumer application can not read data sent from ADS fast enough (a slow consumer).
You can implement the application performance to speed up picking up events in the Application callbacks to make the application and API consume data from the ADS faster. The suggested solutions are:
1. Process incoming data with minimize time in the callback methods, onRefreshMsg(), onUpdateMsg, onStatusMsg(), etc. Basically, the longer the application is held in this method, the more events are added up in the queue, which leads to the overflow scenario and disconnections. Avoid making database and/or other blocking calls in the methods. The application may have additional thread to process the received event separately.
2. You can improve the application performance by using the horizontal scaling to distribute the process of response/update messages between multiple CPU cores while running a single process on the machine. This would increase the response message throughput of the application.
Below is the example design of the application applied horizontal scaling with 4 OMMConsumer threads:
All OmmConsumer threads are configured to the same host/port to make the application creates multiple connections to the same TREP infra.
Please be informed that the horizontal scaling may not be fully beneficial to applications when the number of threads is higher than the number of the machine CPU’s cores.
Please see the horizontal scaling implementation example from EMA Java’s example410__MarketPrice__HorizontalScaling application. The example is available at <EMA 3.2 package>\Java\Ema\Examples\src\main\java\com\thomsonreuters\ema\examples\training\consumer\series400\example410__MarketPrice__HorizontalScaling folder.
Hi Wasin, Thank your kind reply. I did try a number of things but could not get sufficient performance. The Consumer, which is as you said slow, wpuld crash typically one to five minutes before the USA market close. Typically when volume is highest. We are trying to subscribe to 4,700 stock names. My solution is to move to the ETA (UPA) Api will see if that fixes things.
What kills the EMA performance is the buffer locks, and the fact that there is only one thread available for unpacking data, and that data is only "valid" within the call back method.
Warmest regards, Mike.
