Hello.

As far as I can tell, this is the expected behavior. The incoming notifications are stacking up in the queues, if the processing code cannot cope with the influx. Every physical system has its limits.

Best regards

Hello.

The EasyDAClient.SharedParameters.Engine.TopicLruSize was basically an artificial limit on how many items can be subscribed at the same time. It has been completely removed and is effectively "infinite".

Use EasyDAClient.SharedParameters.ClientParameteres.RequestQueueSize instead of EasyDAClient.SharedParameters.Client.RequestQueueSize. It is not directly related to performance, though - it is a size limit on a queue that sits between your code and the low-level execution of your requests. Set it to at least a number that is higher than the number of items you are subscribing to in a single operation. Also set EasyDAClient.SharedParameters.Client.ResponseQueueSize to the same value or higher. EasyDAClient.SharedParameters.Client.LinkCallbackQueueSize may also need an increase - the value it difficult to asses because it depends on how updates are "chunked" by the server - but there is not much harm in setting any of these limits too high.

You may experiment by setting EasyDAClient.SharedParameters.Client.TopicProcessingIntervalTimeout and EasyDAClient.SharedParameters.Client.TopicProcessingTotalTimeout to higher values (e.g. both 2 times as high, and if that helps, repeat that increase etc.). They influence how/whether the client code will split your single large SubscribeMultipleItems into chunks.

All of the above applies only when you target .NET Framework and use the "native client" implementation (the default). When targeting .NET Core/.NET 5+ or when you switch to "NetAPI client", the settings are ignored.

Note that 100K is very large number.

Best regards