Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Exceeding the maximum thoughput of my processor on many OnItemChanged()

More
22 Mar 2017 18:39 #5030 by support
The answer depends on where precisely the bottleneck is, and that cannot be determined without detailed analysis.

We know that in .NET applications, the number you have stated would be suspiciously low. One can expect 5,000 changes per second or more there.

The QuickOPC COM layer is built on top of .NET (the transformation layer is mainly provided by Microsoft). We have not measured the COM API for performance; it is clear from the described principle that it must be slower, but I do not know how much.

If the limitation is indeed in the transformation layer or on the consuming side, then intuitively, I would say that your proposed approach should help.


Regards

Please Log in or Create an account to join the conversation.

More
22 Mar 2017 18:31 #5029 by support
Semantically, the effects (end result) should be the same.
But there is potentially a huge difference in performance (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20instead%20of%20looping.html ).

SubscribeMultipleItems will (normally) pass all the items to the server in a single call. Calling SubscribeItem in a loop will result in far too many roundtrips between the client and the server.

Please Log in or Create an account to join the conversation.

  • m.baumgartner
  • Topic Author
  • Visitor
  • Visitor
22 Mar 2017 09:37 #5027 by m.baumgartner
Also, can you confirm that subscribing individually to items with the SubscribeItem() procedure ends to the same result as subscribing to multiple items at once with the SubscribeMultipleItems() procedure?

Please Log in or Create an account to join the conversation.

  • m.baumgartner
  • Topic Author
  • Visitor
  • Visitor
22 Mar 2017 09:17 #5022 by m.baumgartner
Hello,

As I'm currently testing out OPCLabs we're facing a limitation in a situation that I may encounter with my application.

I've implemented a TEasyDAClient that subscribe to 1500 tags with a RequestedUpdateRate of 1000ms (1s).
These tags are simulation tags set up to change to a random value every second. This leads to our application receiving 1500 notifications per seconds (this is the stress test I wanted).

As I instantiated the TEasyDAClient in the main thread of my application I'm observing that my application cannot process these OnItemChanged() events quick enough to keep up. Depending on the computer it's running on, it goes from 250 to 550 max processed events per seconds. I understand that there has to be a limit to what can be done on a single core of my processor.

250 operations per seconds should be enough for our current usage of the application but we might hit that ceiling in a near future.
My question is, what do you recommend in terms of implementation if we want to process over 500 operations per second.

Should I implement N threads, each subscribing to X different items?

Thank you for your help.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.044 seconds