Hello.

You wrote "If I am now understanding correctly, the Isolated property will force separate client connections, but they would still operate in a single thread and not concurrently. ".

I would still like to correct this a little, in two aspects:

1. The current design is such that they should already operate concurrently. But the concurrency may have its limits. That's why 2 or 5 or 10 may appear to work fine, but not 80. It might be possible to improve on that, but such behavior is not considered a problem. It would be a product improvement, not a bug fix.
2. If, however, also a small number (2 or 5) connection negatively influences themselves, it would be a more serious issue, possibly a bug.

So yes, please try to do the "small" test you proposed. If it shows a problem, I will investigate.
For larger test, not only I have not an imminent idea of how to do it, but neither do I have actual plans to do so, because it is not the design aim. We would have to discuss such things and plan upfront. During our meeting in spring, I have stated precisely that: That the product development is done while keeping performance in mind, but is not currently tested or optimized for that specifically. Intentionally.

Best regards

Hello.

As you also noticed, the forum post you link to had to do with OPC "Classic". It has been fixed, but it is unrelated to OPC UA, which is what your customer is using.

Before addressing the issue, I want to correct the misconceptions in your text. They do not affect the answer, but I feel it necessary to explain.

1. The title is "EasyUAClient Instances Set to Isolated are Not Behaving Independently". But to be precise, that's not what Isolated is for. When set to True, it means that operations performed through such EasyUAClient objects will have connections (sessions) separated from other EasyUAClient objects. The connections are still maintained by the same, single "engine" object in the background. The EasyUAClient instances are not completely "independent" in this sense.

2. If the client is creating one EasyUAClient for each PLC (UA server) he is connecting to, in terms of the connections (sessions), the result will be the same as if they had only one EasyUAClient. But it gives them the possibility to e.g. call some operation on one of them on a thread, and in parallel on a second one from another thread an another operation.

We do not test with 80 or so servers here and specifically target performance with high loads. It would be possible to do performance tuning for that, but it would be a relatively large effort that we will need to plan and schedule. Out of my head, the reasons for the declining performance might be e.g.

a) some inefficient locking (serialization) in QuickOPC code
b) use of threads from a thread pool - which might get scarce with high number of servers.

How do you plan to replicate it?

Regards