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.

Optimize requests in an ASP.NET Web Application

More
02 Jul 2015 10:18 #3256 by support
Thank you for the additional information.

"Web application" is quite a broad term, so when giving recommendations, I need to qualify that with which approach is used to make them.

One common scenario is that OPC data are needed when the page is generated. And, the page request may come either "randomly" (based on how the users navigate through the app), or periodically (enforced page refresh and other approaches). For this scenario, EasyDAClient has two main features: 1) It keeps the OPC connection open for a configurable time between the requests, and 2) it observes the pattern of "read" calls, and sets up an additional OPC subscription, in an attempt to have the data already available when the request comes (and not having to do the actual OPC Read).

The above two features generally do improve the performance, but also bring in the timing "instability" that you have observed, because inevitable fluctuations (or simply randomness) in the rate of page requests cause different behavior depending on whether the data momentary available is "fresh enough" or not. It is possibly to disable this (one part of it is to specify the reading from Device or Cache and not by ValueAge) - the result is more predictability in terms of timing, but most likely slower performance on average. See also www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads .

If the application needs to "observe" values of certain tags for extended periods of time, *and* you can set up objects that run on a global scope (not per page request), then it is generally wiser to use OPC subscriptions on this global scope, and store the incoming values (from easyDAClient, they arrive through events or callbacks) into some data structure. The page code can then just pick up the latest data values from this data structure, without further calls to OPC or even EasyDAClient. Implementing this requires some extra care (such as synchronizing the access to the shared data structure), but for some applications it is really the best approach.
The following user(s) said Thank You: plarac.andres

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

  • plarac.andres
  • Topic Author
  • Visitor
  • Visitor
01 Jul 2015 14:10 - 01 Jul 2015 14:14 #3253 by plarac.andres
Replied by plarac.andres on topic Optimize requests in an ASP.NET Web Application
Hi,
In the case that I want to use subscriptions, why becomes more complicated in a web application? If I use subscriptions, which would be the advantages?

How often do you perform this code? Is it on a regular basis (if so, what is the rate of execution), or is it inside a page rendering code, and you cannot predict when the request is made?

This code is executed regularly every 1.5 seconds (updating part of the page that it contains the values of the tag)

The other thing to consider are the read parameters. You can specify to read from Device, from Cache, or (dynamically determine the source) by ValueAge. The Device is always slowest. The default is to read by ValueAge of 1000 milliseconds, meaning that depending on when the last value of read, you could get a value "from memory", or the device has to be contacted.

Read from the device is slower, but in the case of using it would be more "stable"? in case there exists a problem of memory that in the long run could take place.

Modbus (serial) is generally relatively slow. With ReadItem or ReadMultipleItems, we do not do different processing (on the client side) based on the data Quality. Therefore, if tags with Bad quality take more time, the reason must be on the server side (and may be perfectly OK when reading from Device is involved).



Yesterday I tried the application with a different opc server and the results were also quite good, then considering your answer the problem is Modbus(serial), thanks for this information.

Finally, according to your experience, for a web application that use this library, which would be the tips to make it more stable in the long run? I am referring to operate several days without stopping. Or if you could give me other tips to improve performance would be even happier. Thanks for the help, you are always available to help and your support is extremely fast. Very nice Job.
Last edit: 01 Jul 2015 14:14 by plarac.andres.

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

More
01 Jul 2015 11:14 #3249 by support
Thank you for details. As a general note, if the intent is to obtain the latest values over a longer time, it is far better to use the subscriptions (although, in a Web application, that might get complicated - I know).

How often do you perform this code? Is it on a regular basis (if so, what is the rate of execution), or is it inside a page rendering code, and you cannot predict when the request is made? The reason I am asking is because we hold the connection to the server for some time. When the next request is done during certain time, the connection is reused. Otherwise, it has to be re-established.

The other thing to consider are the read parameters. You can specify to read from Device, from Cache, or (dynamically determine the source) by ValueAge. The Device is always slowest. The default is to read by ValueAge of 1000 milliseconds, meaning that depending on when the last value of read, you could get a value "from memory", or the device has to be contacted.

Modbus (serial) is generally relatively slow. With ReadItem or ReadMultipleItems, we do not do different processing (on the client side) based on the data Quality. Therefore, if tags with Bad quality take more time, the reason must be on the server side (and may be perfectly OK when reading from Device is involved).

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

  • plarac.andres
  • Topic Author
  • Visitor
  • Visitor
30 Jun 2015 16:38 - 30 Jun 2015 16:51 #3246 by plarac.andres
Replied by plarac.andres on topic Optimize requests in an ASP.NET Web Application
Hi,

1- I use operations only for read. I'm not using Subscribe methods.

2- Only 3 Tags.

3- I dont use loops to read the tags, only the method ReadMultipleTags and the best times of the request of the application is when i use this method and giving the result to a variable of type AVtqResult[].
For example:
	DAVtqResult[] tagsFinales = client.ReadMultipleItems("Matrikon.OPC.Simulation.1", tags);
4- I only have one method that use ReadMultipleItems to return all the values of the three Items.
For example:
       DAItemDescriptor[] tags = new DAItemDescriptor[3];
                tags[0] = new DAItemDescriptor("TAGS.AMPERS");
                tags[1] = new DAItemDescriptor("TAGS.TIEMPO_DISPARO");
                tags[2] = new DAItemDescriptor("TAGS.TIEMPO_REINICIO");
 
       DAVtqResult[] tagsFinales = client.ReadMultipleItems("Matrikon.OPC.Simulation.1", tags);


Thanks.
Last edit: 30 Jun 2015 16:51 by plarac.andres.

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

More
30 Jun 2015 16:22 #3245 by support
Thanks for describing what you have done so far and the results. Instead of giving you a whole bunch of recommendations at once, I suggest we do it interactively - I'll ask a few questions and then reply based on your answers.

1. What is are the primary methods you are using on EasyDAClient?
"Single-shot" operations (ReadXXXX, WriteXXXX), or are you using SubscribeXXXX?

2. How many tags are we talking about?

3. Are you calling the methods on EasyDAClient for them in a loop, or do you use a method with "Multiple" in its name?

4. If you are doing a "single-shot" Read, is it a method that returns just a value (ReadItemValue, ReadMultipleItemValues), or a method that returns a whole VTQ (ReadItem, ReadMultipleItems?)

Thank you

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

  • plarac.andres
  • Topic Author
  • Visitor
  • Visitor
30 Jun 2015 16:13 - 30 Jun 2015 16:15 #3244 by plarac.andres
Hi, I been working in a web aplication in asp.net with c#. I use the EasyDAClient to read data from plc, a portion of the page is recharged with native ajax each 1,5 seconds. This is for update the reads from the plc.
I have been trying to optimize the application so that it could run of the most ideal and rapid form.
so this is my situation.

1 - I improved the code in the best possible way.
2 - To test the performance of the application, I installed "Matrikon Opc Server for Simulation" to simulate the tags and the result of the work of my application is 120ms to 180ms by request (sometimes much less). I was very satisfied with this outcome, because there were no gaps or loss of information.
3- When I saw the previous result, I started to simulate the plc in a different way. I download a plc modbus simulator called "mod rssim" and the OPC server "Matrikon OPC Server for Modbus". The results of the operation of my application were not good, 280 ms to 340 ms per request in tags with good quality. In tags with poor quality times were even greater, of 400ms to 500ms with much delay, gaps and accumulation of petitions.

Then I find myself in this situation and I would like to ask if you could give me some tips to optimize the performance of an application in asp.net using code behind with EasyDAClient or maybe some kind of configuration.

I know that this is not a specific question, but any help will be very welcome
Thanks and regards.
Last edit: 30 Jun 2015 16:15 by plarac.andres.

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

Moderators: support
Time to create page: 0.066 seconds