November 26, 2019
we are facing a problem with the message above. The problem occurs with prosys-opc-ua-sdk-for-java-4.6.2-1636 when we try to establish connection to 50 OPC UA test server and subscribe 50 Items for each server. The issue leads also to overrun in our System and various timeouts due high CPU load caused by Prosys stack. All test OPC UA Servers are based on Prosys sampleconsoleserver. Could you please advise how to proceed with this issue?
Thank you in advance
March 16, 2017
There are some other topics here in the forum which are related to this response message … maybe you’ll find some information there
November 26, 2019
April 3, 2012
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.
November 26, 2019
We are looking for solution to connect up to 70 OPC UA Servers and overall 2500 monitored Items from single communication node.
Our answers for your queries:
-> Are all the 50 items in a single subscription (per client/connection)?
Yes, all 50 items are in single subscription.
-> Are all the clients in the same JVM?
Yes, all clients are in the same VM
-> Are the servers in same?
Yes, also the test servers are in the same VM (in the real life, all of them are separted devices)
-> Are servers same JVM in the clients are?
No, the servers are running on separted host
-> How many cores you have in your CPU?
-> How much RAM you have?
On servers and clients side JVMs run with -Xmx1024m -Xms512m
-> What kind of hardware you use?
Industrial PC with Debian Linux on Intel(R) Atom(TM) CPU E3827 @ 1.74GHz, 2G RAM
-> What are the parameters of the items and Subscriptions i.e. publishinginterval/maxkeepalivecount/lifetimecount?
The publishing interval in the mentioned test scenario set to 200mSec, all other parameters are default
What are the limits for Prosys SDK? How many connections could be managed? How many items per connections are allowed?
April 3, 2012
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
(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.
Most Users Ever Online: 267
Currently Browsing this Page:
rocket science: 52
Guest Posters: 0
Newest Members:LimaomoT, eulaallcot, brain7955241817, barbaravillalobo, widallet, erminovski, etsuko73u61420, donnyblaxland, DonaldHAp, kelvin6887
Moderators: Jouni Aro: 918, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne BostrĂ¶m: 726, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 24, Teppo Uimonen: 21, Markus Johansson: 36, Niklas Nurminen: 0, Matti Siponen: 163, Lusetti: 0
Administrators: admin: 1