Having so many connections makes this a different situation.

Do you really need _that many_ of them in a real case?

Are all the 50 items in a single subscription (per client/connection)? Are all the clients in the same JVM? Are the servers in same? Are servers same JVM in the clients are? How many cores you have in your CPU? How much RAM you have? Or well, in general what kind of hardware you use? What are the parameters of the items and Subscriptions i.e. publishinginterval/maxkeepalivecount/lifetimecount?

Due to the legacy of the “stack level designs” most lower level blocking operations rely on shared threadpools, which has 64 Threads. This is shared between all clients and servers of the same JVM. This can be changed via StackUtils.setBlockingWorkerThreadPoolCoreSize(number of threads), though it should be noted that the default 64 is pretty much the only tested number.

It is a bit complicated to write a good answer to this, so I’ll skip a lot of details for now.

Please try with
uaClient.setInitTypeDictionaryAutoUsage(false)
uaClient.setInitTypeDictionaryOnConnect(false)
(call before calling connect).

Only helps if you do not need custom Structure support. Also if you use any UaNode-based APIs such as UaClient.getAddressSpace().getNode() typically it would be better to have those flags as true (though we are aware that this either is not optimal, but it is … kinda better than what we used to have, but maybe not in this particular case), but assuming I found the right spec sheet for the CPU https://www.intel.com/content/www/us/en/products/sku/78478/intel-atom-processor-e3827-1m-cache-1-75-ghz/specifications.html), it is like from 2013. I would not do any _new_ projects with this old hardware (it is different if you already have them) regradless of it’s speed. And it is also a very low-end CPU maybe even back then. Like, SDK should … run, like it runs on a raspberry pi, but at least my expectation would be like more of running a single server with some few clients connected to it. Note that this is just a guess, as I do not have that exact hardware here to test and profile on.

Basically SDK-wise we sort of have no limits (except some “safety limits” in the server side in how many sessions can be made etc.), so it basically depends on how much the hardware can do, i.e. “as much as you have tested to work on the hardware you have”. I can note however that most of the things “take a Thread”. UaClient needs 2 Threads per instance, on the server side we need multiple per UaServer. One Thread per Session of the server (assuming the Session uses Subscriptions). One per a Subscription made to a Session. Plus then the common thread pools mentioned earlier (one “blocking” and another “non-blocking” with CPU cores amount of threads). On the server side each service request is handled on the blocking work pool.

Typically we’ll try to improve the things our customers wants from us, though performance related questions have not been common these days. Basically saying we’ll optimize things when that is needed thus things might not be … that optimized as there has not been that much demand for it.