Max number of OPC DA subscriptions with OPC DA Surrogate
We are investigating the best way to set up our Application Servers and Connectivity Servers for communication to another system with OPC DA Surrogate.
If we look into the manuals we see that it is possible to connect > 10.000 signals with OPC DA Surrogate. The best way to do this is with dedicated Application Servers. But another table in the manual says that the the max number OPC items from external subscription per surrogate process is only 2000 items. And it says that you are allowed to run a maximum of 4 OPC DA Surrogate processes on a server.
What is the best solution if we want to communicate for example 20.000 signals with OPC DA Surrogate to another system? Do we need 3 Application Servers because one server can only handle 4 x 2000 = 8000 signals?
Answers
As always, its very difficult to present good limitations on OPC DA communication. There are too many variables, e.g. client behavior; synchronous, asynchronous, mix of both, etc.
Then we must remember that the surrogate server is just a common "facade" for what OPC sources there are inside the system. There are true OPC servers like e.g. AC 800M but there are also emulated servers like General Properties, Alarm Global Properties, Lock Server properties, etc.
For a client on the outside, all these properties seem to belong to the surrogate server, but in fact the surrogate is just a relaying agent, a "facade".
To achieve good performance, the client need to adjust itself for what the true server(s) are capable of. Some OPC sources in the 800xA system are "strong" and can tolerate a high volume of reads, writes and subscriptions (e.g. the AC 800M OPC server in combination with a well tuned controller and MMS communication) while other sources are weaker (don't want to hang out anyone here but you can surely guess some) or are unable to withstand high volume of writes, e.g. General Properties.
You must also look at the client's behavior; if it just does "Connect, AddGroup, AddItem, SetActive, Advise" (asynchronous method of subscribing to properties) you can often expect maximum performance sustainable by the true OPC server behind the surrogate's facade.
But if you client does not use active groups and instead show behavior like "Connect, AddGroup, AddItem, **SetInActive**, SyncRead, SyncWrite, SyncRead, SyncWrite)" performance will typically be much less.
Several other techniques/options exist as well (device read, cache read, etc). The full picture must be accounted for, not just number of items.
Then we must look into the 10k items you mention.
Do they constantly change every second (temperature transmitters without deadband/filter) or seldomly change (digital transmitter or integer values without noise)?
Whatever figures we put in the System Guide, you will be able to "break it" with certain client behavior. The published figures does not account for rate of change or client's choice of subscription model and if the client is only reading or is reading/writing.
You can probably have 50.000+ items flowing through a surrogate if the true source can handle it and the client just uses "permanent" advise requests.
For high volume transfers, it might be advisable to connect the external client directly to the source OPC server (bypassing the 800xA framework). This gives maximum performance but in the same eliminates security and audit options. Also, if the client need access to a variety of items from different sources, going via the framework will save some work since all items will be addressable from the surrogate which have a total picture of what is in the system compared to connecting directly to one of the sources.
A client with a mixture of reads, subscribes and writes will have less performance than a sole reader. Especially if synchronous methods are used (the surrogate will stop all background activities when carrying out a synchronous request from a client). If possible, separate readers from writers and stay off synchronous methods if possible.
When writing through a surrogate with "Operator Action" audit logging enabled; evaluate if Audit Trail should be exempted for this instance of surrogate, e.g. if the writes are made from some control loop and not humans. The exempt is made by changing a registry key in the server the surrogate runs in. Google AKS for the registry key to change.
With some more input from you I could provide a more detailed answer.
/Stefan
Parameters influencing the performance of the subscription:
1) Number of OPC groups, items, update rates
2a) Subscription type synchronous/asynchronous, readonly, read/write or writeonly.
2b) Subscription parameters: cache/device read, active/inactive items, Advise/Refresh, etc
3) Expected rate of change of items ("noisy temperatures" or stable integers)
4) Source OPC server(s) on the inside of the system
Each OPC server on the inside may have limitations or best practises that need to be adjusted for.
E.g. The 800xA for Advant Master OPC server is tenfold (or more) better at 1, 3 or 9 seconds update rate with asynchronous Advise()-based subscriptions to a subset of properties on each object type. Any other type of subscription or writes will cause the 800xA for Advant Master OPC server's performance to drop sharply.
Add new comment